Re: Object Model Pictures
Nathan, 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
Re: Object Model Pictures
HaloO, 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!
Re: Object Model Pictures
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. 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
Re: Object Model Pictures
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
Re: Object Model Pictures
On Mon, Sep 12, 2005 at 03:10:55PM -0400, Stevan Little wrote: > 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