Re: Role Method Conflicts and Disambiguation (Theory-theoretic take)
Here's how I see roles. This is just an attempt to formalize our
concepts so that the answer becomes an obvious truth rather than a
decision.
A role is an interface with some default implementations. Here's an example:
role Foo {
# anything that conforms to Foo must provide a foo() method
# if one is not provided, this body is used instead
method foo () { say hi }
# anything that conforms to Foo must provide a bar() method
# if one is not provided, then there is an error
method bar () {...}
# anything that conforms to Foo must provide a baz() method
# if one is not provided, then an instance variable is used instead
has $.baz;
}
role Bar {
# anything that conforms to Bar must provide a bar() method
method bar() {...}
}
# this is a conditional: anything that conforms to FooBar also
# conforms to Foo and Bar
role FooBar {
does Foo;
does Bar;
# the requirement for the implementation of a bar() method is
# carried over[1]
}
This is a sort of suspension. If you ignore the roles Foo and Bar,
you have simply a role FooBar that has three requirements: foo(),
bar(), and baz(), where foo() and baz() have defaults. When you
compose this into an empty class, you will get not a conflict but a
missing method error. bar() was not implemented.
Now, let's say that bar() was given a default implementation in Foo.
Then FooBar would be a fully-defined role with no requirements.
Let's say that bar() was given a default implementation in both Foo
and Bar. That's a conflict. But let's follow suit and pretend that
Foo and Bar didn't exist. If you try to compose in FooBar, you will
get an ambiguity, which can be resolved by defining your own bar().
So clearly, FooBar simply has a required foo() again.
To summarize, as we'll use this later:
Foo:foo() default, bar() default, baz() default
Bar:bar() default
FooBar: bar() required
So then we take that, and say that we can give a default
implementation for this now-required method. FooBar may disambiguate.
Moving on.
role Baz {
does Bar;
}
By my free-derivation (or composition in this case, I guess)
principle, Baz is now equivalent to Foo. If you think of them as
interfaces, it makes perfect sense. Baz provides no additional
implementations, nor imposes any additional requirements, and thus you
must do precisely the same things to conform to Baz as to Foo.
Baz: bar() default
Now:
class MyClass does FooBar does Baz { }
Here's where the theory proposal comes in, yet again. The definition
of a class is just the definition of a role together with a
(syntactically impossible) declaration of a concrete type. Creating
the class is erroneous if the role is not fully-defined. So let's
just look at the role half:
role MyClass {
does FooBar;
does Baz;
}
Now we ignore the inner workings of FooBar and Baz. This is a good
idea, as it lets us refactor freely, as long as it looks the same from
the outside. Recall that we had:
Baz: bar() default
FooBar: bar() required
So clearly Baz fulfills FooBar's requirements, and MyClass is a
fully-defined role.
Okay, how did that happen? What was the formality that we actually used?
It was the fact that at each stage of the game, we summarized the
defaults and requirements for each role, ignoring the internal makeup
(i.e., what roles were composed into it, etc.).
And it sounds correct to me.
Luke
[1] Perhaps we even require declaration. We probably shouldn't, in
the name of keeping Perl Perl. Any good documentation system ought to
catalog all the dependencies.
Re: Role Method Conflicts and Disambiguation (Theory-theoretic take)
On 29/10/05, Luke Palmer [EMAIL PROTECTED] wrote:
Moving on.
role Baz {
does Bar;
}
By my free-derivation (or composition in this case, I guess)
principle, Baz is now equivalent to Foo. If you think of them as
interfaces, it makes perfect sense. Baz provides no additional
implementations, nor imposes any additional requirements, and thus you
must do precisely the same things to conform to Baz as to Foo.
Baz: bar() default
You meant to write 'equivalent to Bar', not Foo, right?
Stuart
Re: Role Method Conflicts and Disambiguation (Theory-theoretic take)
On 10/28/05, Luke Palmer [EMAIL PROTECTED] wrote: Here's how I see roles. This is just an attempt to formalize our concepts so that the answer becomes an obvious truth rather than a decision. A role is an interface with some default implementations. -snip- Now we ignore the inner workings of FooBar and Baz. This is a good idea, as it lets us refactor freely, as long as it looks the same from the outside. I would say that this isn't just a good idea; it's at the core of what distinguishes composition from inheritance. With classes and inheritance, you keep all of the baggage that accumulates at each step, on the off-chance that some as-yet unknown descendant might need it. With composition the only baggage that a role keeps is the baggage that is directly relevant to itself. Whatever gets tossed aside can be composed in separately later on if it's needed. Recall that we had: Baz: bar() default FooBar: bar() required So clearly Baz fulfills FooBar's requirements, and MyClass is a fully-defined role. Okay, how did that happen? What was the formality that we actually used? It was the fact that at each stage of the game, we summarized the defaults and requirements for each role, ignoring the internal makeup (i.e., what roles were composed into it, etc.). And it sounds correct to me. Me, too. -- Jonathan Dataweaver Lang
Re: Role Method Conflicts and Disambiguation (Theory-theoretic take)
On 10/28/05, Luke Palmer [EMAIL PROTECTED] wrote: [snip] It was the fact that at each stage of the game, we summarized the defaults and requirements for each role, ignoring the internal makeup (i.e., what roles were composed into it, etc.). So, in theory, one should be able to ask any given role What do you provide? as well as What do you require?. (I'm not saying that the syntax should be available, but that the information to answer those questions should be easily calculable.) One concern I have is that I would like to believe that a role is a group of related behaviors that provides a functionality. So, if Foo does roleA and I as the user of Foo asks Do you do roleA? and it replies Yes, then I can make some assumptions about Foo's functionality. Otherwise, this devolves into interfaces. Interfaces suck, especially given as they're limited to naming. Now, if we were to say that all roles, by default, provide multimethods, then conflicts only occur for methods that have identical dispatching semantics. At that point, it's truly a conflict and would need to be resolved by the composer (whether that's a role or a class). Now, it's obvious why a class would have to resolve that conflict. I would say that a role would have to resolve the conflict is that a role should present a consistent API to the rest of the world. In other words, I want to be able to depend on the fact that classA does roleAB means something in terms of the functionality that classA provides to me. I don't want it to be a glorified can() check. That does no-one any good. Rob
Re: Role Method Conflicts and Disambiguation (Theory-theoretic take)
On 10/28/05, Rob Kinyon [EMAIL PROTECTED] wrote: Now, it's obvious why a class would have to resolve that conflict. I would say that a role would have to resolve the conflict is that a role should present a consistent API to the rest of the world. In other words, I want to be able to depend on the fact that classA does roleAB means something in terms of the functionality that classA provides to me. I don't want it to be a glorified can() check. That does no-one any good. Most certainly. Implicit in a role or a theory is its algebra (though we've talked about QuickCheckish ways to make it explicit). For instance, technically the VectorSpace theory only requires you to define identity, addition, and scalar multiplication. However, in order to honestly do VectorSpace, addition has to be commutative, which is something that the compiler usually is not able to check. And that's why you have to explicitly say that your class does the role, rather than it just inferring that from the methods you provide. You may have named your methods the same, but there's no guarantee that you obey the role's algebra. By saying that your class does the role, you are promising that these methods do indeed obey the necessary algebra. So in a way, it's a kind of glorified can(). But in another way, it does guarante certain kinds of behavior from the implementing objects. If you do a role and override a method that violates what the role is supposed to guarantee, then you don't really do that role, even though you do as far as the compiler knows. It's a conceptual contract, not a computationally rigorous one. On the computational level, a role is little more than an interface with defaults. Luke
Re: Role Method Conflicts and Disambiguation (Theory-theoretic take)
Luke, On Oct 28, 2005, at 9:44 PM, Luke Palmer wrote: It was the fact that at each stage of the game, we summarized the defaults and requirements for each role, ignoring the internal makeup (i.e., what roles were composed into it, etc.). This then imposes somewhat of an ordering with role composition. The role tree will need to be traversed breadth first, and conflicts/ requirements resolved on a level by level basis. And it sounds correct to me. It sounds correct to me as well (in theory,.. get it ,... in theory :P). However, I do worry about how it will work out in practice. Part of the goal of roles (and I have been preaching this one since the hackathon) is that they are easier to use than multiple inheritance, have fewer headaches than mix-ins and are more useful than interfaces. Imposing ordering as described above may make things easier, or it may make things harder, only time and experience will tell. I am going to give this some more thought over the weekend, and see what I come up with. Stevan
