On Thu, Jul 14, 2005 at 03:27:53PM +1200, Sam Vilain wrote: : Can I present an alternative way of viewing them, which I don't think : contradicts with what I've understood of them so far from the : Apocalypses and Synopses documents. : : First a couple of definitions; : : A "runtime class" is a package name, and a collection of functions : that form a "dispatch table". There are actually two tables - one : for private and one for public methods.
Private and public methods are probably stored in a single table, but the private methods just happen to have a name starting with :. : The public table links to : "superclasses" where further dispatch may occur. Er, the concept of superclasses is not hidden in the dispatch table. Different dispatchers may have different ideas about method ordering, so the ISA information is really just passive trait data that must be interpreted by cooperation between dispatchers and meta classes. As such it's really a separate datum than the list of available methods. (Certainly, a given dispatcher might want to cache parental links in the current package's symbol table, but that's an optimization, and depends on the particular dispatcher's semantics.) : A "method" on a Role or a Class is a function that takes two : implicit arguments; a dispatch table for private method lookups, and : one for public methods lookups. The private dispatch table is bound : when the function is added to a runtime class, but the public : dispatch table is bound as late as possible (or until the class is : closed in some situations). I think you must be using "private" to mean something different than A12, but that's okay as long as we realize that. I'd prefer to couch things in terms of instantiated and uninstantiated generics, but we're probably just talking about the same things with different terms. : Here's the meat: : : A Class is then a Role that gets its runtime class created, and all : its methods' private dispatch tables bound at declaration time. I'd say the generic methods are forced to instantiate with either the default implementation provided by the role or the overriding implementation provided by the class, or by some combination of them if the class's method wants to delegate to the role's method. : A Role, on the other hand, leaves methods that can't be called, : until they are bound into a "runtime class". So they _look_ like : they are flattened as the runtime classes are composed, unless you : are introspecting to the sufficient level. : : The "runtime class" would be the ::Type objects, and the real Class and : Role objects what you get from the .meta objects. Which you consider "realer" depends on whether you're a Platonist or an Aristotelian, but okay. I would say your "runtime class" is the representative proxy for all objects of its type, while the meta classes are in charge of the dirty work. So who's "realer", the Senator who stands in front and smiles, or the Senator's aides who stand behind and frown? :-) : This might be a half empty / half full thing, I just thought you might : find that description interesting. Note that I don't deal with "state", : I'm just treating attributes as if all they are is a set of accessor : functions, which store in an unspecified&unimportant location. We're just basically assuming a role can behave like a parent class to the extent necessary to manage its state on behalf of the real object, so for instance it can have its own BUILD submethod that somehow magically gets incorporated into the object's own BUILD process. But politically the role is just that of the biological parent, not the guardian parent. You could almost think of a collection of roles as sort of a sperm and egg bank. Well, that's enough metaphors for today, at least till next week. Larry
