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.


Reply via email to