On Mon, Sep 17, 2012 at 9:57 AM, Nick Wellnhofer <[email protected]> wrote: > On 17/09/2012 11:55, Nathan Kurz wrote: >> VTables disappear. Unfortunately, this is the less fleshed out part >> of my plan. I'm serious, though. >> ... > > I wonder how you want to make virtual method dispatch work with this kind of > scheme.
I'm terrible on terminology, and even worse when it comes to mapping these to Clownfish. Am I right that all of our object methods are 'virtual' now, so this you're wondering about how method inheritance works at all? Unfortunately, this core essential feature is part of what I referred to as "not yet fleshed out". The silly straightforward way would be to just chain the functions. New_foo() is stubbed to call Parent_foo(), which in turn may choose to call Grandparent_foo(). Sounds slow, but it's possible that Link TIme Optimization might substitute be able to re-optimize it. The trickier way would be to do it with symbol aliasing. Define New_foo() as an alias for Parent_foo(), and let the runtime linker handle it behind the scenes like any other shared symbol. But while this works on paper, I don't know how it fares in practice: http://blog.omega-prime.co.uk/?p=121 Or am I many steps behind you and I'm missing the elephant? --- Part of my interest in this direction is that it doesn't affect how we handle the instance variables. Keeping them. By keeping that independent (and ideally just a simple struct) we keep the complexity down. Another point is that I don't think we have to move in this direction in any hurry. I think adding some padding to futureproof our current VTables with hold us through a major release cycle if needed. I think the general approach of this paper: http://2f.ru/holy-wars/fbc.html Old, and C++, but a nice simple approach. Add padding where you think you'll need it, and have an "ioctl" type safety net. We may also be able to use their trick of padding both the top and bottom of the VTable to allow us to move things between parent and child. This is definitely a blue sky approach, but I think it's a particularly dangerous one. --nate
