On Oct 28, 2005, at 11:13 PM, Luke Palmer wrote:
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 multi
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 10/28/05, Ruud H.G. van Tol <[EMAIL PROTECTED]> wrote:
> John Williams:
>
> > ($x *=2) += 1;
>
> Or ($x *= 2) ++;
>
> Maybe the comma should be taught a new trick:
>
> $x *= 2, ++, /= 3;
>
> meaning
>
> $x = (($x * 2) + 1) / 3;
>
> Or RPN-like:
>
> $x #= 2* 1+ 3/;
Oh, gee, why don't
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
John Williams:
> ($x *=2) += 1;
Or ($x *= 2) ++;
Maybe the comma should be taught a new trick:
$x *= 2, ++, /= 3;
meaning
$x = (($x * 2) + 1) / 3;
Or RPN-like:
$x #= 2* 1+ 3/;
--
Grtz, Ruud
> But IMHO the reduction in typing for this relatively minor issue is not
> really worth the surprise to newbies at seeing operandless operators.
AMEN!
Rob
On Tue, 25 Oct 2005, Juerd wrote:
> For comparison, here is the same code snippet again. First with, and
> then without explicit $_.
>
> With:
>
> given ($subject) -> $_ {
> $_ ~~ s/foo/bar/;
> $_++;
> $_ x= 2;
> $_ ~= "!";
> }
>
> Without:
>
> given ($su
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
On Thu, 27 Oct 2005, Darren Duncan wrote:
Not sure if this matter was resolved on a previous discussion, but here goes
Definitely is has been discussed at least once, that I know, for I asked
this myself, but from a somewhat more mathematical pov. You can find a
copy of my mail here:
http:
On 10/28/05, Darren Duncan <[EMAIL PROTECTED]> wrote:
> One thing I would like to be able to do is this:
>
>@baz = cross([1,2],[3,4]); # yields ([1,3],[1,4],[2,3],[2,4])
>
> And alternately, this:
>
>for cross([1,2],[3,4]) -> $foo,$bar { ... } # loop has 4 iterations
I already proposed thi
28 matches
Mail list logo
