-
Notifications
You must be signed in to change notification settings - Fork 32
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
Support Inheritance #310
Comments
I dug into this a bit, and I think this may unfortunately be blocked by #4. To expose a syntax where an object can invoke a parent's function, there needs to be a mechanism to discover the method using a char*. Currently, the full set is known, so in At first I thought I could simply daisy chain inheritance of I considered trying to build a map of candidates for each layer of inheritance, but this is difficult to do and maintain This problem may be easier to solve after migrating to C++20, so I may take a detour to do so. Much of the C++17 implementation exploits tricks in the type system to workaround not having string literals (i.e. non type templates). |
Moving to 1.2 since this is a non-trivial amount of work. |
I'm unlikely to finish this work. This feature would certainly be useful, and necessary for terse enum class representations, but I'm scaling back efforts to only critical fixes / work. |
Currently, class definitions must re-declare all of their parent classes interface if they want to be used, which is repetitive.
Also, subclasses must
static_cast
themselves tojobject
s to be used in a context their subclass is required which loses type safety.enum classes are basically syntactic sugar for a subclassing, so this likely needs to be implemented first.
It will be nice to unify the type system to enable interface of
Object
throughout Java. That said, Kotlin'sAny
is not Java'sObject
, so any solution should not presume this.The text was updated successfully, but these errors were encountered: