>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> * Objects have properties you can fetch and store by name DS> * Objects have methods you can call DS> * Objects have attributes you can fetch
and store
Well... I'm not sure about that. Classes can store data in object attributes, but there isn't necessarily a public API through the PMC to do this. Basically if you can get to it through a PMC's vtable, it was on the "Objects have" list. I'm not sure that storing into an attribute should be easily doable from the outside.
Methods have access to an object's internal bits, so the class methods can poke into slots in the attribute array directly, which is probably how they'll work.
DS> * You can fetch a hash of all the properties DS> * When fetching or storing a generic property, you may call a method DS> instead, as methods win
what about methods overriding attributes? or are attribute accessors just methods?
Attribute accessors are methods. If an object wants accessors, it exports lvalue methods (potentially--they don't strictly have to be lvalue if it's read-only) for them.
DS> Objects may actually be composite objects, if we're doing inheritance DS> via delegation, for when we inherit from a class of a different type. In DS> that case the delegated object has a property on it that refers to the DS> 'master' object that represents the ultimate child class' object. This DS> is done with a "PARENT" property on the
on the what?
The delegated object. D'oh!
So if class A isa B, and B is a perl 5 hash-object-thingie, the object that B creates would have the "PARENT" property stuck on it, pointing ot the A object. That way B can make method calls on its object the right way. (If B couldn't get back to the containing object transparently we'd trim off a lot of the inheritance tree and we don't want that)
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.
Sorry. Parent == derived class, child == parent class. Bad choice of words on my part.
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'?
Don't need it. The object the class 'has' is stored in an attribute slot, and the class is in the "is" array, since it really 'is' that foreign class, albeit with some magic to make it work. (The parent property and such)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
