On Mon, Sep 24, 2012 at 3:09 AM, Nick Wellnhofer <[email protected]> wrote: > I think we're going a bit in circles here.
Not exactly circles. I suggesting that we go back to the last fork and check our map, so that we're sure that we're on the right road. > Your proposal looks very much > like Marvin's proposal in the first message of this thread (one offset > global per ivar). Yes, but more built out version with hopefully more safety and usability. Both are still broad strokes. > If you're only concerned with making access of parent class ivars more > convenient, we could achieve this with a couple of macros on top of my > proposal: > > #define Sub_sub_num(self) Sub_GET_IVARS(self)->sub_num > #define Sub_sub_float(self) Sub_GET_IVARS(self)->sub_float > #define Sub_base_num(self) Base_GET_IVARS(self)->base_num > #define Sub_base_float(self) Base_GET_IVARS(self)->base_float I'm not only concerned with that, but yes, this would be much better than not having them. If we take your path, I'd want to add these. It's really the base assumptions that concern me more. I'll try to stick to one at a time for a bit. [from earlier] > Note that my approach doesn't work with cross-parcel access of member > variables, not even with > accessing member vars of superclasses if the superclass comes from another > parcel. But I think > that's something we could live with. I don't see this as acceptable, although both you and Marvin seem to view it as partially a positive. My feelings come from two separate directions: 1) While this might be acceptable for Lucy, if we were treating Clownfish as a separate project I think this would leave it dead in the water. I don't think that a general purpose object hierarchy system would be well served by not allowing a user defined child class to have easy access to the class it inherits from. 2) I don't think it works well for Lucy either. I think the main way people will write compiled extensions is to subclass an existing scorer, matcher, or posting format. I think discouraging access to instance variables will make this task much harder than it needs to be, and force them to copy-and-edit entire class hierarchies. To focus on something specific, consider Peter's custom scoring demo: http://www.mail-archive.com/[email protected]/msg00249.html What would it take to write this as a compiled extension rather than an interpreted one? I think that almost everything that is done would benefit from having the same level of access to instance variables as the parent. Why do we want to discourage this, and what would the alternative be? My hope is that user defined extensions can operate at the same level of efficiency as the core, and that over time we can "de-privilege" the core classes so that improvements to each are shared. I don't see what we gain by making this distinction greater. Or is the intent to discourage such access within the core distributed classes as well? --nate
