I'm curious as to what the instant problem is. I'm familiar with fragile base class becoming an issue in a few cases:
1) We're handing out headers + precompiled libraries to end users. They're going to build subclasses, and later they might re-link their applications with newer versions of the libraries, having skipped re-compilation in error. Boom. 2) The codebase is huge, and under frequent extreme refactoring. Re-compiling big pieces of the application after making a small modification to a widely-used base class is prohibitiively expensive. Yuk. 3) The codebase's build dependencies aren't correctly stated. When changing a base class and doing a rebuild (without forcing a clean rebuild), you end up with a surreptitiously broken application. *Sad trombone* Which of these (or which other scenarios) are we running into? - Kurt On Mon, Sep 17, 2012 at 5:55 AM, Nathan Kurz <[email protected]> wrote: > 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
