>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 1:52 PM -0500 3/9/03, Uri Guttman wrote:
DS> is done with a "PARENT" property on the >> >> on the what?
DS> The delegated object. D'oh!
DS> So if class A isa B, and B is a perl 5 hash-object-thingie, the object DS> that B creates would have the "PARENT" property stuck on it, pointing ot DS> the A object. That way B can make method calls on its object the right DS> way. (If B couldn't get back to the containing object transparently we'd DS> trim off a lot of the inheritance tree and we don't want that)
so any class X that inherits from B must also modify the PARENT property in B? that sounds like PARENT is a hash of the classes which inherit from B.
Yep. Basically if the inheriting class is of a different type, such that the parent class must be inherited with delegation, then when the parent object is instantiated it gets the PARENT property on it. Messy in some ways, but I don't see any way around it.
<i hate all the variant OO names, parent/super/etc. so damned confusing. maybe we should have a special parrot OO section in the glossary>
Works for me.
>> it would be helpful to clarify which direction you mean with >> parent/child with regard to delegation. i take it the parent object gets >> the original method call and it delegates it to the child object that >> the parent owns. i use 'own' (others say 'has') for the delegation >> relationship and i mean the parent owns the child which will get the >> delegated call. note that a parent could own multiple children of the >> same name and delegate different parent methods to different >> children. 'has' doesn't cover that case as well as own. minor semantic >> difference but worth mentioning.
DS> Sorry. Parent == derived class, child == parent class. Bad choice of DS> words on my part.
so please resend that out soon (try 4) with the edits.
<ditto on the glossary note :)>
DS> Each class is represented by a PMC with an "is", and "does" property, DS> which are arrays of parent classes and parent interfaces, DS> respectively. The default method dispatch vtable function should respect DS> both the is and does list--personally I'm thinking we should DS> pre-populate the method table for a class since we're going to do DS> notifications, but we can defer that until later. >> >> what about 'has'?
DS> Don't need it. The object the class 'has' is stored in an attribute DS> slot, and the class is in the "is" array, since it really 'is' that DS> foreign class, albeit with some magic to make it work. (The parent DS> property and such)
how does that handle which methods in the 'owner' object get mapped/delegated to which methods in the 'owned' object? damian's delegate module has a map for that with owner method names mapping to attribute (owned object)/method pairs. not all methods of an owned object need to be accessible via the owner's interface. also how do you handle multiple owned objects and method mapping?
Ah, this isn't for the Damian "We do Interesting Things with delegation" stuff. This mechanism is in specifically to handle inheriting from an incompatible parent class. Stuff like Damian wants can be handled completely in user-code, so it should be.
At some point someone will come up with a clever general way to handle this, in which case we'll look into rolling it into the base object system, but for now, in the interests of what simplicity we can muster, we're going to duck the issue.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
