On Sun, Jul 14, 2013 at 4:41 AM, Nick Wellnhofer <[email protected]> wrote: > On Jul 14, 2013, at 02:22 , Marvin Humphrey <[email protected]> wrote: >> Classes within the Clownfish runtime still have members defined within >> their object structs and do not use IVARS. I'm of two minds as to whether >> we should go and update them to use IVARS for the sake of consistency, >> pound-defining the IVARS_OFFSET symbols as integer constants by default but >> allowing for the possibility of an override. I'm not sure there's any use >> case where we'd need a variable-sized object head. > > I can't think of a use case neither.
Yeah. It would theoretically remove a barrier to using the same runtime shared object with multiple hosts, but I don't think we ever want to do that. Among other things, a full implementation of that would require changing our dynamic method invocation functions to locate the vtable pointer at a variable offset rather than an offset that's fixed at compile time. And of course we want the host to have full control over installation, so that you can upgrade Clownfish in the Python 3 install tree and not affect your Perl install. I'm still tempted to do it for the sake of consistency. It would be nice to be able to say "Clownfish object struct types are completely opaque. Instance variables may only be accessed via IVARS." > Now it's time to finish the dynamic method offsets. I held it off because I > hoped we could find a way to avoid the need for offset vars for every > method. Having a single offset var per novel method would simplify the > initialization of method offsets. I think the only downside is the thing > with moving novel methods to a superclass. Maybe we should simply require > manual intervention to support this use case? It should be rarely needed in > practice. Haha, I feel your irritation. We've done all that work on thunks, which was largely motivated by the space issue! By the way, your work on the thunk benchmarking has never come up on the dev list (branch `method-dispatch-benchmark`). It was very illuminating! I don't think the use case of moving a novel method to a superclass is all that rare. It may not happen every day, but I'll bet it will happen multiple times over the lifetime of any project of significant size. I think it's important that we not burden developers with having to understand that kind of edge case detail. IMO, we have some serious work to do paring down the existing Clownfish header language, removing some experimental misfeatures that are no longer justified, and we should be reluctant to add any API complexity right now. I think it's premature to compromise the API for the sake of a space issue which probably won't affect performance. If you're amenable, can we please go with what we have now, with the understanding that we'll keep trying to find better implementations in the future? Marvin Humphrey
