On Nov 2, 2005, at 9:02 PM, Jonathan Lang wrote:
Let's say you have this:
role A {method foo() { code1; } }
role B {method foo() { code2; } }
role C does A does B {
method foo() { A::foo(); }
method bar() { B::foo(); }
}
Should the following be valid?
role D does C { method
On Nov 2, 2005, at 9:02 PM, Jonathan Lang wrote:
Let's say you have this:
role A {method foo() { code1; } }
role B {method foo() { code2; } }
role C does A does B {
method foo() { A::foo(); }
method bar() { B::foo(); }
}
Should the following be valid?
HaloO,
Rob Kinyon wrote:
On Nov 2, 2005, at 9:02 PM, Jonathan Lang wrote:
Let's say you have this:
role A {method foo() { code1; } }
role B {method foo() { code2; } }
I think, A and B might just be aliases to the *identical* structural type
because the only constraint that both roles
On Tue, Nov 01, 2005 at 04:02:04PM -0800, Jonathan Lang wrote:
True enough; but it needn't be true that d have the same tools
available to resolve the conflicts that c has.
There are three ways that a role can deal with a conflict:
1. choose one of a set of available methods to call its
On Wed, Nov 02, 2005 at 16:37:29 -0600, Jonathan Scott Duff wrote:
On Tue, Nov 01, 2005 at 04:02:04PM -0800, Jonathan Lang wrote:
True enough; but it needn't be true that d have the same tools
available to resolve the conflicts that c has.
There are three ways that a role can deal with a
Jonathan Scott Duff wrote:
People keep using the word hierarchy when talking about roles and I
keep thinking that it is the one word that definitely does NOT apply.
Heirarchies are for classes and inheritance relationships, not roles
and composition.
In my world view, a role that is composed
On 11/2/05, Jonathan Lang [EMAIL PROTECTED] wrote:
Let's say you have this:
role A {method foo() { code1; } }
role B {method foo() { code2; } }
role C does A does B {
method foo() { A::foo(); }
method bar() { B::foo(); }
}
Should the following be valid?
role D does C
On Fri, Oct 28, 2005 at 14:19:46 -0400, Stevan Little wrote:
Yuval,
On Oct 28, 2005, at 10:59 AM, Yuval Kogman wrote:
On Thu, Oct 27, 2005 at 22:19:16 -0400, Stevan Little wrote:
Now, at this point we have a method conflict in suspension since
(according to A/S-12) method conflicts do
Yuval Kogman wrote:
Stevan Little wrote:
If we allow the class to decide if things break or not, then we
potentially allow for the system to be in a very unstable state. A
method conflict means that neither method gets consumed, and at
that point we have a gapping hole in our class.
On 11/1/05, Jonathan Lang [EMAIL PROTECTED] wrote:
In the third case, I'd be inclined to say that passing the buck is
equivalent to creating an undefined version of your own - that is, not
addressing a conflict involving method x is equivalent to saying
method x ($arg) { ... }. IOW, a class
1. choose one of a set of available methods to call its own.
2. create a version of its own.
3. pass the buck.
#1 and #2 are identical. Stevan and I have always viewed #1 as a
special case of #2. If you want to choose a method to call, then
create a method of your own and have it wrap the one
Rob Kinyon wrote:
1. choose one of a set of available methods to call its own.
2. create a version of its own.
3. pass the buck.
#1 and #2 are identical. Stevan and I have always viewed #1 as a
special case of #2. If you want to choose a method to call, then
create a method of your own
On Thu, Oct 27, 2005 at 22:19:16 -0400, Stevan Little wrote:
Hello all,
I have a question about method conflict resolution works for roles, and I
cannot seem to find this in any
of the Apoc/Syn documents.
Here is the basic issue:
role Foo {
method foo { ... }
method bar
On Thu, Oct 27, 2005 at 10:19:16PM -0400, Stevan Little wrote:
I have a question about method conflict resolution works for roles,
and I cannot seem to find this in any of the Apoc/Syn documents.
Here is the basic issue:
role Foo {
method foo { ... }
method bar { ... } # we
On Fri, Oct 28, 2005 at 04:59:18PM +0200, Yuval Kogman wrote:
If, OTOH we have a diamond inheritence:
You mean composition. There is no role inheritance :)
role A { method foo { ... } }
role B does A {};
role C does A {};
class D does A does B { };
I'm assuming
On Fri, Oct 28, 2005 at 10:38:31 -0500, Jonathan Scott Duff wrote:
You mean composition. There is no role inheritance :)
Oops ;-)
I'm assuming you meant
class D does B does C { ... }
I always do that crap... =(
I'm not sure we need to resolve the conflict.
It depends on when
Yuval,
On Oct 28, 2005, at 10:59 AM, Yuval Kogman wrote:
On Thu, Oct 27, 2005 at 22:19:16 -0400, Stevan Little wrote:
Now, at this point we have a method conflict in suspension since
(according to A/S-12) method conflicts do
not throw an error until a role is composed into a class. This
On Oct 28, 2005, at 11:17 AM, Jonathan Scott Duff wrote:
On Thu, Oct 27, 2005 at 10:19:16PM -0400, Stevan Little wrote:
I have a question about method conflict resolution works for roles,
and I cannot seem to find this in any of the Apoc/Syn documents.
Here is the basic issue:
role Foo {
On Oct 28, 2005, at 11:38 AM, Jonathan Scott Duff wrote:
On Fri, Oct 28, 2005 at 04:59:18PM +0200, Yuval Kogman wrote:
If, OTOH we have a diamond inheritence:
You mean composition. There is no role inheritance :)
role A { method foo { ... } }
role B does A {};
role C does A
On Fri, Oct 28, 2005 at 02:29:36PM -0400, Stevan Little wrote:
I should be allowed to create a role with all sorts of conflicts which
I leave for the classes to deal with.
Er, why? I've read this sentence several times and I'm really having
trouble grasping why anyone would deliberately create
On Fri, Oct 28, 2005 at 06:23:28PM +0200, Yuval Kogman wrote:
On Fri, Oct 28, 2005 at 10:38:31 -0500, Jonathan Scott Duff wrote:
Er, there is only one $:foo. X doesn't have any private members, nor
does Y (because they're roles). Only C has private members. So,
modulo the multiple
On 10/28/05, Jonathan Scott Duff [EMAIL PROTECTED] wrote:
Roles can hold instance data that will be composed into a class. What
I'm saying is that if you have two roles:
role X { has $:foo; }
role Y { has $:foo; }
And a class that's composed of them:
class Xy does X does Y { ... }
That
On Oct 28, 2005, at 2:54 PM, Jonathan Scott Duff wrote:
On Fri, Oct 28, 2005 at 02:29:36PM -0400, Stevan Little wrote:
I should be allowed to create a role with all sorts of conflicts
which
I leave for the classes to deal with.
Er, why? I've read this sentence several times and I'm really
On Oct 28, 2005, at 3:04 PM, Jonathan Scott Duff wrote:
But, I'm probably wrong about this as the X role may have methods that
use $:foo in one way and the Y role may have methods that use $:foo in
some other, incompatible way, so perhaps there will be a conflict just
as when there are 2
On Oct 28, 2005, at 3:45 PM, Rob Kinyon wrote:
Doing it any other way leads to the following: if A does rA and B isa
A and B defines an attribute that conflicts with the one provided by
rA, how on earth is that supposed to be detected? Especially given
that the inheritance tree of a class can
To me, the distinguishing feature between the role and class concepts
has always been that roles lack internal structure: you don't have to
worry about any hierarchies of what went into creating the role; you
just have to pay attention to what attributes and methods it will add
to whatever class
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()
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
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
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
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
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
Hello all,
I have a question about method conflict resolution works for roles,
and I cannot seem to find this in any of the Apoc/Syn documents.
Here is the basic issue:
role Foo {
method foo { ... }
method bar { ... } # we will use this later :)
}
role Bar {
method foo { ... }
33 matches
Mail list logo
