On 17/09/2012 11:55, Nathan Kurz 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?
IMO, we should try to support all of this if it doesn't come at too high
a cost.
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.
I think the idea is really to improve Clownfish in general, and break it
out as a stand-alone product. If we separate the Clownfish core classes
from Lucy, we'll already be faced with all the binary compatibility issues.
In the long run, Lucy should also benefit from making the Clownfish
object system more modular, especially wrt compiled extensions.
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.
I wonder how you want to make virtual method dispatch work with this
kind of scheme.
Nick
