Object Model Pictures
Stevan Little
In my never ending quest to implement the Perl 6 object model, I have
started drawing pictures. Here is the latest version:
http://svn.openfoundry.org/pugs/perl5/Perl6-MetaModel2.0/docs/
p6_object_model.jpg
(and for OmniGraffle users: http://svn.openfoundry.org/pugs/perl5/
Perl6-MetaModel2.0/docs/p6_object_model.graffle)
I would appreciate any comments/questions/suggestions anyone has to
offer.
A few things to note:
- Roles are not yet included in this, I am of the opinion that the
core MetaModel should be role-less, and roles will be laid on top of
the core metamodel post-bootstrapping. This makes the most sense
currently, however, this may change down the road, either way I think
it is an implementation detail as long as it "looks" the same when
everything is loaded.
- the word "meta" is used to describe the "three-circle" items.
Please do not read to much into this terminology, "meta" simply means
"you should not touch this unless you *really* know what you are
doing". Suggestions on better names are welcome.
- the reason Foo and $foo are smaller is because they are "user
created" items.
Okay, thats all my caveats, fire away please.
Stevan
Nathan Gray
> In my never ending quest to implement the Perl 6 object model, I have
> started drawing pictures. Here is the latest version:
>
> http://svn.openfoundry.org/pugs/perl5/Perl6-MetaModel2.0/docs/
> p6_object_model.jpg
Awesome diagram.
> I would appreciate any comments/questions/suggestions anyone has to
> offer.
In my never ending quest to understand the Perl 6 object model, I think
it has become clearer each time I've discovered another document or
picture.
Thank you Stevan!
> A few things to note:
>
> - Roles are not yet included in this, I am of the opinion that the
> core MetaModel should be role-less, and roles will be laid on top of
> the core metamodel post-bootstrapping. This makes the most sense
> currently, however, this may change down the road, either way I think
> it is an implementation detail as long as it "looks" the same when
> everything is loaded.
Yep, someone needs to make a diagram about Roles, too.
-kolibrie
Stevan Little
On Sep 12, 2005, at 3:56 PM, Nathan Gray wrote:
> Yep, someone needs to make a diagram about Roles, too.
Here yah go.
http://svn.openfoundry.org/pugs/perl5/Perl6-MetaModel2.0/docs/
p6_role_model.jpg
I am planning on making Roles self-bootstrapping, so the class(Role)
will actually be the first Role in the system. From there, Class will
do Role, and Role will do Role. This also means that all the
instances of Class will also do Role, which means that classes
automatically can also be used as Roles.
Here is a mini-meta-model variation which implements this on a very
basic level:
http://svn.openfoundry.org/pugs/perl5/Perl6-MetaModel2.0/docs/
MiniMetaModel_w_Role.pl
There is also an ASCII diagram here:
http://svn.openfoundry.org/pugs/perl5/Perl6-MetaModel2.0/docs/
misc_drawings.txt
I was planning on getting Role into the metamodel by the end of this
week, but it seems $work might get in the way.
Stevan
Nathan Gray
> http://svn.openfoundry.org/pugs/perl5/Perl6-MetaModel2.0/docs/
> p6_role_model.jpg
>
> I am planning on making Roles self-bootstrapping, so the class(Role)
> will actually be the first Role in the system. From there, Class will
> do Role, and Role will do Role. This also means that all the
> instances of Class will also do Role, which means that classes
> automatically can also be used as Roles.
Thanks for the pictures, Stevan.
So every time a class does a new role, a new instance of the class is
created as the role.
If a class does three roles, there will be three role instances of
the class, as well as the class' own instance of itself, and a user
instance.
When a method is called on the user instance, it asks the class instance
if it can do the method, and the class instance looks at the methods in
the class, and then at the methods in each role, and dispatches to the
appropriate method definition.
A role can be "done" by several classes at once, because a new instance
is created for each class, specific to the class.
Methods defined in a class are not clobbered by methods defined in a
role. Rather, methods in a role are only catalogued by the class
instance if it does not already have a method definition for that name.
The order that a class does roles is significant, because if two roles
define the same method, only the first one is catalogued by the class
instance.
-kolibrie
TSa
Nathan Gray wrote:
> The order that a class does roles is significant, because if two roles
> define the same method, only the first one is catalogued by the class
> instance.
Ups, this contradicts the concept of class composition which in the
above case should raise an error instead of relying on the order of
definition.
--
$TSa.greeting := "HaloO"; # mind the echo!
Stevan Little
On Sep 21, 2005, at 9:02 AM, Nathan Gray wrote:
> On Tue, Sep 20, 2005 at 08:16:23PM -0400, Stevan Little wrote:
>
>> http://svn.openfoundry.org/pugs/perl5/Perl6-MetaModel2.0/docs/
>> p6_role_model.jpg
>>
>> I am planning on making Roles self-bootstrapping, so the class(Role)
>> will actually be the first Role in the system. From there, Class will
>> do Role, and Role will do Role. This also means that all the
>> instances of Class will also do Role, which means that classes
>> automatically can also be used as Roles.
>>
>
> Thanks for the pictures, Stevan.
>
> So every time a class does a new role, a new instance of the class is
> created as the role.
Nope. The Role interface is (for the most part) a subset of the Class
interface, well at least the important bits are. So I manually
bootstrap the role(Role) into the class(Class), this then means that
Class.does(Role). THis means that all instances of Class (all the
user defined classes) themselves also do Role. This means that all
Classes then become interchangeable with Roles. No new class or role
instances need to be created, it is all inherited behavior from the
class(Class).
> If a class does three roles, there will be three role instances of
> the class, as well as the class' own instance of itself, and a user
> instance.
No, Roles are disposed of once class composition is complete. Part of
the class composition process will be to consume any Roles which the
class does. THe consumption process takes all the methods and
attributes from the Role and actually adds them into the class. After
that, the role can essentially be discarded (unless another class
uses that same role).
>
> When a method is called on the user instance, it asks the class
> instance
> if it can do the method, and the class instance looks at the
> methods in
> the class, and then at the methods in each role, and dispatches to the
> appropriate method definition.
The dispatch is always in the class since role methods are consumed
into the class.
> A role can be "done" by several classes at once, because a new
> instance
> is created for each class, specific to the class.
>
> Methods defined in a class are not clobbered by methods defined in a
> role. Rather, methods in a role are only catalogued by the class
> instance if it does not already have a method definition for that
> name.
> The order that a class does roles is significant, because if two roles
> define the same method, only the first one is catalogued by the class
> instance.
Class methods are used first, if the class method is not there, then
the Role method is used. If there is a conflict with Role methods,
neither Role method is used. By making all conflicts behave this way,
we make Role order not-significant. Also If two Role methods
conflict, the class consuming the roles must implement that method,
otherwise it is a fatal error.
Stevan
>
> -kolibrie
>
>