Objects =======
* Objects have properties you can fetch and store by name
* Objects have methods you can call
* Objects have attributes you can fetch
* You can fetch a hash of all the properties
* When fetching or storing a generic property, you may call a method instead, as methods win
* You can fetch a method PMC from the object
* You can fetch the object's Class PMC
All of these have vtable entries in the PMC: get_prop, set_prop, get_attrib, set_attrib, get_prop_hash, get_method, call_method, get_class. (Some already have names, I'm doing this from memory)
No, you can't set a method or the property hash from an object PMC. Arguments with good reasons to do so will be cheerfully read and not implemented. :)
PMCs are responsible for making sure the get/set property stuff calls methods if that should happen per the PMC's owning language spec.
If the property hash should call methods when things are fetched from it (because there are override fetch methods or something) then the PMC is responsible for returning a hash PMC with appropriate active get/set methods attached to it.
Objects may actually be composite objects, if we're doing inheritance via delegation, for when we inherit from a class of a different type. In that case the delegated object has a property on it that refers to the 'master' object that represents the ultimate child class' object. This is done with a "PARENT" property on the
Note that objects do *not* have to have classes. Variables don't even have to *be* objects, as such--plain integers can implement all this stuff if they want. We're OO-fuzzy here.
Classes =======
Classes are indirectly responsible for how objects behave, as the class constructs the initial vtable that gets assigned to each object. (Well, the PMC class, and language level classes will all have a custom generated PMC class for them) The only thing actually semi-required of classes is a set of metadata. It's semi-required in that any class that uses the metadata *must* use it in the way we prescribe. Anyone's free to do things differently, in which case it's just a matter of implementing the right vtable code and suchlike things. Doable, if not actually simple.
Parrot's base class mechanism support multiple inheritance, delegated inheritance, and inherited interfaces. They correspond, more or less, to "is", "has" and "does", and that's what we're going to refer to them as. We are class-based, since that's what perl 6, python, and ruby all do. Some of the other object systems are interesting, but we're not going to bother with them here. Not our focus.
Each class is represented by a PMC with an "is", and "does" property, which are arrays of parent classes and parent interfaces, respectively. The default method dispatch vtable function should respect both the is and does list--personally I'm thinking we should pre-populate the method table for a class since we're going to do notifications, but we can defer that until later.
Each class has the following semi-required properties (The names aren't fixed):
* does - Array of immediate parent interfaces
* is - Array of immediate parent classes
* needs - A count of the attributes for this class (class only, not parent classes)
* attributes - an array of attribute names for this class (not parent classes, just this class)
* object_style - What type of object this is. 0 = no object, 1 = parrot base object, 2 = delegated object
* core_functions - An array of the core functions for the class. We'll get to those in a moment.
Core Functions ==============
These are in the core_functions property array, and are considered part of the base parrot class/object mechanism. They're here since we may need to do something fancier than a plain most-derived-class-method call.
* allocate - Called when we need to create a new object. Must return a PMC
* initialize - Called when we need to initialize the object that allocate returned
Destruction is part of the vtable, so classes should just fill that in in their initialization code.
Method Dispatch ===============
The engine will have a function to determine the "closest" method or sub in a tree, given a signature. We walk the tree of classes based on the metainformation and do our best to find the right method. (No, we've not talked about method metadata. Assume we have some)
The base method dispatch looks for actual sub/methods, then AUTOLOAD, then multimethod dispatch. We do *not* do AUTOLOAD for more 'special' methods (no AUTOLOADed DESTROY methods, for example) so if a language requires them it should instantiate an empty method (one with a signature but no code) as when we call those we do invoke the class' autoloading mechanism to find the body.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
