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 impo
> 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
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 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?
>
> r
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 c
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 dea
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 i
On 11/1/05, Jonathan Lang <[EMAIL PROTECTED]> wrote:
> 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.
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 y
> 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 on
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
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 cla
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 confl
On Fri, Oct 28, 2005 at 14:04:35 -0500, Jonathan Scott Duff wrote:
> That there will not be two slots for $:foo in Xy, but only one.
>
> 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, inc
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 comp
Rob Kinyon 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
>
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 depe
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 give
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 w
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
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()
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 yo
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 be
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 methods
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 h
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 { ..
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 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 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 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 {
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
me
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 depend
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 as
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 { ... }
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 { ... }
> m
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 { ... }
36 matches
Mail list logo
