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

Add class support #66

Open
6 of 15 tasks
perlun opened this issue Sep 2, 2020 · 1 comment
Open
6 of 15 tasks

Add class support #66

perlun opened this issue Sep 2, 2020 · 1 comment
Labels
enhancement New feature or request epic A feature being worked on during a long time
Milestone

Comments

@perlun
Copy link
Collaborator

perlun commented Sep 2, 2020

This is not going to be trivial, partially since our current TypeReference implementation presumes that variables and functions always return a valid CLR type. Well, a class being defined in the global (or local) scope, isn't a CLR type (at least not until we make the move to make all Perlang classes exist as valid CLR types as well - this move will come at some point to make Perlang code interop with existing .NET code properly, being able to implement .NET interfaces by Perlang classes etc), so that's at least one of the challenges. There will probably be numerous others as well.

Here's the Crafting Interpreters chapter about the jlox implementation of classes: https://craftinginterpreters.com/classes.html. It doesn't help us that much since the static typing support we added in #54 has made things much more complex. We are already quite different from jlox and there is unfortunately no-one apart from ourselves that we can ask for help about how things work in our code base...

Initial features (supported in 0.1.0)

Features likely to get implemented, but not as of the initial effort (0.2.0 or "Later")

  • User-defined classes: define classes in Perlang code and be able to instantiate them.
    • This was started in the 0.1.0 milestone, but the code that existed was removed in (parser) Make class reserved keyword #183. Adding it here for reference. We should put it back, and make it work equally well as in Lox.
  • C#-defined classes: be able to instantiate classes defined in C#. This would be very useful and help us to add nice things like an IntList (mutable List<int>, for lack of generics)
    • We'll need a new keyword for this or similar, unless we go the Ruby approach and just tack .new() after the class name. Making constructors be nothing else than plain static factory methods does have a few advantages, but it makes things like final fields (which must be initialized statically or in the constructor) way harder to achieve.
  • Inheritance: while this is nice and a fundamental in OOP, this is a "more advanced" feature and might get implemented a bit later. We are not hostile to OOP in any way, so I am not opposing it, just deferring it slightly.
  • Visibility: public, private, protected, internal, protected internal (similar to package-private in Java, which unfortunately can only be specified by not explicitly giving a visibility. This is one of the design deficiencies of the Java language from my perspective)

Features that are likely to not ever get implemented (i.e. "non-goals")

  • Multiple inheritance. While useful sometimes, it can cause the diamond of death problem and in general, increases complexity of a computer system without adding enough value to warrant the cost.

Implementation details

Implemented parts (included in 0.1.0)

Remaining parts

  • Support for instantiating classes.
  • Support for calling methods on instances
  • Support for fields and/or properties
  • Support for defining static methods
  • ...probably a bunch of other things as well
@perlun perlun added enhancement New feature or request epic A feature being worked on during a long time labels Sep 2, 2020
perlun added a commit that referenced this issue Sep 2, 2020
Noted while working on #66, but extracted to a separate PR for reviewability.
perlun added a commit that referenced this issue Sep 2, 2020
Again, this is a preparational commit to make room for #66. I concluded that we had some if/else logic here where it made some sense to try to use the best parts of OOP instead, namely polymorphism.

Will this have a significant impact on making #66 easier and more achievable? Perhaps, perhaps not, but it felt like a reasonable small step that would be better off extracting from my WIP branch instead of trying to do "too much" at one time. It's not like adding class support is by any means a trivial task anyway, so anything that can help that branch be more focused and to-the-point is a win.
@perlun perlun pinned this issue Sep 5, 2020
perlun added a commit that referenced this issue Sep 20, 2020
…ive classes (#79)

Continues the work to get #66 implemented.
@perlun perlun added this to the 0.2.0 milestone Oct 19, 2020
@perlun perlun unpinned this issue Mar 12, 2022
@perlun perlun modified the milestones: 0.2.0, "Later" Jun 13, 2022
@perlun
Copy link
Collaborator Author

perlun commented Jun 13, 2022

Unclear about how/if this will get implemented. I'll mark it as "Later" for now and we'll give it some thought/time; there are other more important things (like arrays/index operator, perhaps struct for dealing with binary file formats etc) which are blocking us more at the moment. It's still possible to design (smaller) programs without proper class and/or OOP support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request epic A feature being worked on during a long time
Projects
None yet
Development

No branches or pull requests

1 participant