Larry Wall wrote:
In addition to what chromatic said, I'd like to point out that you've got the abstraction levels backwards by my lights: these days I tend to think of the class as a restricted form of role. A class is restricted to having to provide a working interface to real objects.
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. The public table links to "superclasses" where further dispatch may occur. 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). 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. 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. 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. Sam.
