>>>>> "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. <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> >> 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? i happen to like owned/has more than most and use it quite a bit more than ISA these days. i would like to see a clean mapping spec like the delegate module has. uri -- Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com ----- Stem and Perl Development, Systems Architecture, Design and Coding ---- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class
