Re: Re: class interface of roles
Jonathan~ On 10/7/06, Jonathan Lang [EMAIL PROTECTED] wrote: TSa wrote: Dispatch depends on a partial ordering of roles. Could someone please give me an example to illustrate what is meant by partial ordering here? Sets demonstrate partial ordering. Let denote the subset relation ship. If A B and B C, then A C for any A, B, and C. However, it is not necessarily the case that A B, or B A, or B == A for any particular A and B. Thus transitivity is preserved, but there is not a guarantee of comparability between elements. http://en.wikipedia.org/wiki/Partial_ordering Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -Stan Kelly-Bootle, The Devil's DP Dictionary
Re: Re: class interface of roles
On 10/6/06, TSa [EMAIL PROTECTED] wrote: HaloO, Stevan Little wrote: As for how the example in the OP might work, I would suspect that super would not be what we are looking for here, but instead a variant of next METHOD. I'm not familiar with the next METHOD syntax. How does one get the return value from it and how are parameters passed? Would the respective line in the equal method then read: return next METHOD($p) and self.x == $p.x and self.y == $p.y; I think that a super keyword might be nice syntactic sugar for this. I think super is not something we would want in Roles, it implies ordering, which defeats the flattening aspect of Roles. IIRC the syntax to call the next method with new args and a return value is this: return call($p) and self.x == $p.x and self.y == $p.y; However, I am not sure I really like the look of that myself. However, even with that an ordering of some kind is implied The only ordering I see is that the class is up from the role's perspective. But thats the whole problem, there is no up in roles, they are flattened. When more then one role is combined and all require the presence of an equal method I think the roles can be combined in any order and the super refers to the class combined so far. IOW, at any given time in the composition process there is a current version of the class' method. The final outcome is a method WALK or however this is called in composition order. Conceptually this is method combination: seen from outside the class has just one type correct method equal. Theoretical background can be found in http://www.jot.fm/issues/issue_2004_01/column4 I do not think method combination should be the default for role composition, it would defeat the composeability of roles because you would never have conflicts. However, I can see the possibility of method combinations in roles being some kind of special case. How that might look from a syntactic perspective I have no idea. I suppose this is again where the different concepts of classes are roles can get very sticky. I have always look at roles, once composed into the class, as no longer needing to exist. In fact, if it weren't for the idea of runtime role compostion and runtime role introspection, I would say that roles themselves could be garbage collected at the end of the compile time cycle. I see that quite different: roles are the primary carrier of type information! Well yes, they do seem to have taken on this role ;). However, roles as originally envisioned in the Traits paper are not related to the type system, but instead related to class/object system. In fact the Trait paper gave it's examples in Smalltalk, which is not a strongly typed language (unless you count the idea that *everything* is an object and therefore that is their type). I think we need to be careful in how we associate roles with the type system and how we assocaite them with the object system. I worry that they will end up with conflicting needs and responsibilities and roles will end up being too complex to be truely useful. Dispatch depends on a partial ordering of roles. Type based dispatch does (MMD), but class based method dispatch doesn't need it at all. The whole fact that dispatching requires roles to be partially ordered actually tells me that maybe roles should not be so hinged to the type system since roles are meant to be unordered. Possiblely we should be seeing roles as a way of *implementing* the types, and not as a core component of the type system itself? I did some experimentation with this in Moose::Autobox, but that is for Perl 5 so I am not sure how relevant it is here. - Stevan
Re: Re: class interface of roles
On 10/6/06, TSa [EMAIL PROTECTED] wrote:
HaloO,
Stevan Little wrote:
On 10/2/06, Jonathan Lang [EMAIL PROTECTED] wrote:
This notion of exclusionary roles is an interesting one, though. I'd
like to hear about what kinds of situations would find this notion
useful; but for the moment, I'll take your word that such situations
exist and go from there.
Well to be honest, I haven't found a real-world usage for it yet (at
least in my travels so far), but the Fortress example was this:
trait OrganicMolecule extends Molecule
excludes { InorganicMolecule }
end
trait InorganicMolecule extends Molecule end
Wouldn't that be written in Perl6 the other way around?
role OrganicMolecule {...}
role InorganicMolecule {...}
role Molecule does OrganicMolecule ^ InorganicMolecule {...}
Which is a nice usage of the xor role combinator.
Well, it does seem to accomplish a similar goal. However, in your
example there is nothing about the OrganicMolecule which will prevent
me from composing it with the InOrganicMolecule, which was the primary
goal of the Fortress example. In addition in the Fortress example the
Molecule role is not coupled to the Organic and Inorganic molecules,
in your example they are.
But IMHO this is just another example of TIMTOWTDI, because your
example achieves similar goals and would likely be a valid design
approach as well.
And from that I could see that given a large enough set of roles you
would surely create roles which conflicted with one another on a
conceptual level rather then on a methods/attribute (i.e. - more
concrete) level.
I don't abide to that. If roles are conceptually modelling the same
entity their vocabulary should conflict also. Well unless some
differing coding conventions accidentally produce non-conflicting
roles. The whole point of type systems relies on the fact that
concrete conflicts indicate conceptual ones!
But part of the power of role composability is that the role itself
does not need to dictate what class it is composed into. So conceptual
conflicts cannot be determined until compostion actually occurs, and
conflicts between two conceptually conflicting roles cannot be
detected until composition time either. And of course there is nothing
to say that two conceptually conflicting roles have a concrete
conflict either (either between methods or attributes).
I think that maybe we need to seperate the concept of roles as types
and roles as partial classes, they seem to me to be in conflict with
one another. And even they are not in conflict with one another, I
worry they will bloat the complexity of roles usage.
My experiences thus far with roles in Moose have been that they can be
a really powerful means of reuse. I point you towards Yuval Kogman's
latest work on Class::Workflow, which is basically a loose set of
roles which can be composed into a highly customizable workflow
system. This is where I see the real power of roles coming into play.
- Stevan
Re: Re: class interface of roles
TSa wrote: Dispatch depends on a partial ordering of roles. Could someone please give me an example to illustrate what is meant by partial ordering here? -- Jonathan Dataweaver Lang
Re: Re: class interface of roles
On 10/2/06, Brad Bowman [EMAIL PROTECTED] wrote:
Sam Vilain wrote:
TSa wrote:
is this subject not of interest? I just wanted to start a
discussion about the class composition process and how a
role designer can require the class to provide an equal
method and then augment it to achieve the correct behavior.
Contrast that with the need to do the same in every class
that gets the equal method composed into if the role doesn't
have a superclass interface as described in the article.
This will be the same as requiring that a class implements a method,
except the method's name is infix:==(::T $self: T $other) or some such.
How does a Role require that the target class implement a method (or
do another Role)?
IIRC, it simply needs to provide a method stub, like so:
method bar { ... }
This will tell the class composer that this method must be created
before everything is finished.
Does the class GenSquare does GenEqual does GenPointMixin line imply
an ordering of class composition? This would seem to be required for
the super.equal hand-wave to work but part of the Traits Paper goodness
came from avoiding an ordering. Composition is just order insensitive
flattening. Conflicts like the equal method in the OP have to be
explicitly resolved in the target class, either using aliases
or fully qualified names. So there's no super needed.
The super in a Role should be late bound, so will have no relevance
when inside the role, but only make sense when composed into a class.
This is probably one of the more confusing points of roles I think.
As for how the example in the OP might work, I would suspect that
super would not be what we are looking for here, but instead a
variant of next METHOD. However, even with that an ordering of some
kind is implied.
I suppose this is again where the different concepts of classes are
roles can get very sticky. I have always look at roles, once composed
into the class, as no longer needing to exist. In fact, if it weren't
for the idea of runtime role compostion and runtime role
introspection, I would say that roles themselves could be garbage
collected at the end of the compile time cycle.
I would like a way to make one Role to require that the target class
does another abstract Role, is there already such a technique?
I am not familiar with one, but I have had this need as well lately in
using Moose roles. We have a concept in Moose (stolen from the
Fortress language) where a particular role can exclude the use of
another role, but not the ability to require it, although I see no
reason why it couldn't be done.
- Stevan
Re: Re: class interface of roles
Stevan Little wrote:
Brad Bowman wrote:
How does a Role require that the target class implement a method (or
do another Role)?
IIRC, it simply needs to provide a method stub, like so:
method bar { ... }
This will tell the class composer that this method must be created
before everything is finished.
Correct.
I suppose this is again where the different concepts of classes are
roles can get very sticky. I have always look at roles, once composed
into the class, as no longer needing to exist. In fact, if it weren't
for the idea of runtime role compostion and runtime role
introspection, I would say that roles themselves could be garbage
collected at the end of the compile time cycle.
Again, you've hit the nail on the head. To elaborate on this a little
bit, the only reason that perl needs to keep track of a role hierarchy
at all is for parameter matching purposes (if Foo does Bar and Bar
does Baz, Foo can be used if a signature asks for Baz).
I would like a way to make one Role to require that the target class
does another abstract Role, is there already such a technique?
I am not familiar with one, but I have had this need as well lately in
using Moose roles. We have a concept in Moose (stolen from the
Fortress language) where a particular role can exclude the use of
another role, but not the ability to require it, although I see no
reason why it couldn't be done.
As I mentioned before, having role Bar require that Baz also be
composed is a simple matter of saying role Bar does Baz.
This notion of exclusionary roles is an interesting one, though. I'd
like to hear about what kinds of situations would find this notion
useful; but for the moment, I'll take your word that such situations
exist and go from there.
I wonder if it would be worthwhile to extend the syntax of roles so
that you could prepend a no on any declarative line, resulting in a
compilation error any time something composing that role attempts to
include the feature in question. So, for instance, you might have
role Bar {
no method baz (Num, Str);
}
class Foo does Bar {
method baz (Num $n, Str $s) { ... } # compilation error: Bar
forbade this method!
}
or
role Bar no does Baz { # granted, the english grammar is all wrong...
}
class Foo does Bar does Baz { # compilation error: Bar forbade the
inclusion of Baz!
}
This is not the same as removing something that a composed role
brought in, which is a separate potentially useful notion. The former
is Foo doesn't play well with Bar; so don't try to use them
together; the latter is Foo can do _almost_ everything Bar can, but
not quite. Mind you, if I ever see something to the effect of Foo
does Bar except baz() as valid syntax, I'll expect a query to the
effect of Foo does Bar? to answer to the negative. This would
include can Foo be used when Bar is asked for?
--
Jonathan Dataweaver Lang
Re: Re: Re: class interface of roles
On 10/2/06, Jonathan Lang [EMAIL PROTECTED] wrote:
This notion of exclusionary roles is an interesting one, though. I'd
like to hear about what kinds of situations would find this notion
useful; but for the moment, I'll take your word that such situations
exist and go from there.
Well to be honest, I haven't found a real-world usage for it yet (at
least in my travels so far), but the Fortress example was this:
trait OrganicMolecule extends Molecule
excludes { InorganicMolecule }
end
trait InorganicMolecule extends Molecule end
And from that I could see that given a large enough set of roles you
would surely create roles which conflicted with one another on a
conceptual level rather then on a methods/attribute (i.e. - more
concrete) level.
- Stevan
