Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design pattern: User-defined functor in Motoko #13

Closed
matthewhammer opened this issue Apr 24, 2020 · 4 comments
Closed

Design pattern: User-defined functor in Motoko #13

matthewhammer opened this issue Apr 24, 2020 · 4 comments

Comments

@matthewhammer
Copy link
Contributor

This issue is tracking the answer to the question: How does one write what could be an SML/OCaml-style functor in Motoko, using the current language features?

As one example (WIP): Adapton functor from the Adapton package.

@matthewhammer matthewhammer self-assigned this Apr 24, 2020
@matthewhammer
Copy link
Contributor Author

The HashMap class from base is doing an instance of this pattern (it accepts types and associated functions in its constructor), but not as a single module/record argument. Still, it serves as another example.

@rossberg
Copy link
Contributor

rossberg commented Apr 27, 2020

Isn't this issue more appropriate for the main Motoko repo? Any decent answer would involve changes to the language.

@matthewhammer
Copy link
Contributor Author

Isn't this issue more appropriate for the main Motoko repo? Any decent answer would involve changes to the language.

Okay, but if we move this discussion, should we also move the other one (about "a style guide")?

(Is this not just another question about style? "Birds of a feather"...?)

@matthewhammer
Copy link
Contributor Author

matthewhammer commented Apr 28, 2020

Summarizing @rossberg from the team meeting:

  • If there's no state, can/should use a function over the class, returning a module (not an object).

(But here I am using state in the returned object, so perhaps a class is best after all?)

  • The class's types would be simpler to define if we could define types with free type vars. That's a language/compiler restriction that may be lifted in the near future.

I think the answer posed by the issue has been sufficiently answered for me, for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants