On Mon, Sep 17, 2012 at 1:49 AM, Nathan Kurz <[email protected]> wrote: > I've been reading along, and will try to put my thoughts into typed > words soon.
Preliminary questions followed by preliminary thoughts: What are the bounds of the problem that we are trying to solve here? Is it fair to summarize it to "we want to be able to add methods and instance variables to base classes without breaking shared libraries that inherit from them? Specifically is it OK to do only this and not worry about breakage that can be easily avoided, like reordering the VTable, and hard to solve stuff like having an intermediate class override something new in its parent? How much pressure is there to reduce the memory footprint of these objects? Are there cases where we are allocating millions of them at a time? Related to this, are we trying to improve Clownfish in general, or only as is required for Lucy? I'd guess that while we should be memory conscious, adding a few bytes per layer of inheritance wouldn't be a problem for our specific uses. Are we OK with requiring module developers to know the precise ancestry of their objects by keeping track of which parent added which variables? I think a lot of the examples require this, but I might be misreading them. If true, this seems like it adds another significant barrier to new contributors. Here'a rough vision of my poorly fleshed out goal having even more transparency than we do now: Each object is just a simple struct. Access is via "foo->name". We do this by padding the parent structs with a couple extra slots in case we need them. If they fill up and we still need more, we can punt to a lookup table as the last entry. We break the Lucy ABI at ever major version and adjust padding as needed. If a class is feeling solid and final, we can remove the padding. If still fluid, we add more. I don't think inability to move a variable from parent to grandparent will really be a problem. VTables disappear. Unfortunately, this is the less fleshed out part of my plan. I'm serious, though. I think we can make the linker do a lot of our work that we currently do ourselves. The VTables would be dispersed into the symbol tables, identified only by naming convention. If you create a class Foo inheriting from Parent, "Foo_function" starts as a symbolic alias for "Parent_function". If you want to override it, you give it a real definition. The collection of symbols within "Foo_*" plus some form of Super is all you've got. Adding methods becomes non-dangerous. Rearranging isn't a problem, because no set order exists. Deleting either creates a clear link time error or everything runs fine. Even moving methods between parent and grandparent doesn't fluster us. I think it's all solvable. My fears are mostly speed, related to the multiple layers of indirect lookups referred to in the previous message. The philosophy I'd like to keep is that we do can lots of complex things within Clownfish, but the finished output is simple C code, and the finished libraries are standard libraries that could have been produced without actually using Clownfish. Instead of creating a new language, we're just generating a standardized binary using some custom made tools that make the job easier. --nate
