HaloO,
I wrote:
role GenPointMixin
{
has Int $.x;
has Int $.y;
is extended
{
That should be spelled 'is also'. How does such an
'is also' block address the former class definition
block? Is it OUTER::? Or SUPER::? The latter would mean
that class extension is a kind of pseudo-inher
HaloO,
I wrote:
And finally the combined class
class GenLocSquare is GenSquare does GenPointMixin
{}
I'm still pondering how one achieves method combination of the
role's and the class' methods. Here are two ideas. The first
is to use an 'is extended' part in the role that re-opens the
cl
Jonathan (>), Carl (>>):
> The only alternative I can think
> of right now would be to disallow even _declaring_ two operators of
> different associativity on the same precedence level... but that kind
> of strictitude doesn't sound very perlish.
That depends on how you phrase the restriction.
Carl Mäsak wrote:
The only alternative I can think
of right now would be to disallow even _declaring_ two operators of
different associativity on the same precedence level... but that kind
of strictitude doesn't sound very perlish.
That depends on how you phrase the restriction. If you phrase
Larry (>):
[...]
The non-chaining precedence level is a bunch non-associative operators
like .. and cmp. Historically, all operators of a particular precedence
level have had the same associativity, so that when you analyze
$a op1 $b op2 $c
you only have to compare op1 with op2 if they're
Larry Wall wrote:
Presumably
$obj does (A,B,C)
could also be made to work even with non-associative does.
Right.
Note that you _do_ want to be able to do something to the effect of
ordered composition in a single statement, though:
role A {
...
method m { ... }
}
On Fri, Oct 20, 2006 at 04:47:04PM -0700, Larry Wall wrote:
: For now the conservative thing is probably that we should just leave
: "does" as non-associative and make you write
:
: $obj.also_does(A,B,C)
:
: or some such if you want to get fancy.
Presumably
$obj does (A,B,C)
could also
On Thu, Oct 19, 2006 at 03:31:18PM -0700, Jonathan Lang wrote:
: Larry Wall wrote:
: >Though actually, now that I think about it, the cascaded notation
: >in S12 is illegal according to S03, since "does" is classified as
: >non-chaining, which implies non-associative.
:
: Wait a minute. Isn't "ch
Larry Wall wrote:
Though actually, now that I think about it, the cascaded notation
in S12 is illegal according to S03, since "does" is classified as
non-chaining, which implies non-associative.
Wait a minute. Isn't "chaining" specifically referring to the idea
that "A op B op C" implicitly be
"Jonathan Lang" schreef:
> role R does A does B does C { ... } # unordered composition
> $x does A does B does C; # ordered composition
> $y does A | B | C; # unordered composition
>
> I'd like to see it done something like:
>
> role R does A does B does C { ... } # unordered com
HaloO,
Hmm, no one seems to read the article! There actually is another class
GenLocSquare that combines GenSquare and GenPointMixin. With that we
get a modified version of my code as follows:
role GenEqual
{
method equal( : GenEqual $ --> Bool ) {...}
}
role GenPointMixin
{
has Int $.x;
TSa wrote:
And while we're at it, could we also introduce the subtype operator <:
and perhaps >: as the supertype operator? This would come in handy for
expressing type constraints in does clauses.
Isn't one of those called ".does()"?
--
Jonathan "Dataweaver" Lang
Ruud H.G. van Tol wrote:
Larry Wall schreef:
> I suspect ordered composition is going to be rare enough that we can
> simply dehuffmanize it to
>
> $x does A;
> $x does B;
> $x does C;
Maybe use a list-like notation?
What happens when you try to mix ordered and unordered compositi
HaloO
TSa wrote:
I would like "does A & B & C" mean the intersection type of A, B and C.
That is a supertype of all three roles. In addition we might need
negation to get what Jonathan Lang envisoned for the Complex type that
does Num & !Comparable. IOW, I'm opting for a role combination syntax
HaloO,
Larry Wall wrote:
You've got it inside out. Unordered is just "does A | B | C" or
some such, the | there really being coerced to a set construction,
not a junction. In fact, & would work just as well. I only used |
because it's more readable. Autocoercion of junctions to sets is,
of c
Larry Wall schreef:
> I suspect ordered composition is going to be rare enough that we can
> simply dehuffmanize it to
>
> $x does A;
> $x does B;
> $x does C;
Maybe use a list-like notation?
$x does (A, B, C,) ;
$x does (A ; B ; C) ;
$x does [A, B, C,] ;
$x does [A ; B ;
Larry Wall wrote:
Though actually, now that I think about it, the cascaded notation
in S12 is illegal according to S03, since "does" is classified as
non-chaining, which implies non-associative. Hmm. We'd have to make
it right associative somehow. Put it in with ** maybe?
Hmm.
Or leave it no
On Wed, Oct 18, 2006 at 01:32:14PM -0700, Jonathan Lang wrote:
: >The | notation is mentioned in S012:1029, by the way. Obviously you
: >still haven't quite memorized all the synopses. :-)
:
: Actually, I was very well aware of that fact.
Oops, didn't realize you were suggesting a semantic chan
Though actually, now that I think about it, the cascaded notation
in S12 is illegal according to S03, since "does" is classified as
non-chaining, which implies non-associative. Hmm. We'd have to make
it right associative somehow. Put it in with ** maybe?
Hmm.
Or leave it non-associative and fo
Larry Wall wrote:
You've got it inside out. Unordered is just "does A | B | C" or
some such, the | there really being coerced to a set construction,
not a junction. In fact, & would work just as well. I only used |
because it's more readable. Autocoercion of junctions to sets is,
of course, c
On Tue, Oct 17, 2006 at 04:22:59PM -0700, Jonathan Lang wrote:
: I've never really been happy with the inconsistency between runtime
: composition and compile-time composition; but my problem has generally
: been with the runtime side of things - in particular, I find the fact
: that "does A does B
TSa wrote:
you wrote:
> I think I found the core of the issue here; it has to do with the
> differences between roles and mixins, with an analogous difference
> between compile-time composition and runtime composition. Details
> follow.
I think we are basically through the discussion. Thank you
HaloO Jonathan,
you wrote:
I think I found the core of the issue here; it has to do with the
differences between roles and mixins, with an analogous difference
between compile-time composition and runtime composition. Details
follow.
I think we are basically through the discussion. Thank you
I think I found the core of the issue here; it has to do with the
differences between roles and mixins, with an analogous difference
between compile-time composition and runtime composition. Details
follow.
TSa wrote:
Jonathan Lang wrote:
> Just to make sure we're speaking the same language: by
HaloO,
Jonathan Lang wrote:
Shouldn't the 'divert' be a trait of the method instead of a key/value
pair on the class?
I thought about doing it that way; but then the class wouldn't know to
look for it when composing the role.
I figure you see the class in a very active role when composing ro
HaloO,
Jonathan Lang wrote:
> TSa wrote:
Note that I think the conflict detection of role methods prevents the
composition of the equal method through the superclass interface.
Just to make sure we're speaking the same language: by "superclass",
you're referring to classes brought in via "is";
TSa wrote:
Jonathan Lang wrote:
> Of course, you then run into a problem if the class _doesn't_ redefine
> method equal; if it doesn't, then what is GenPointMixin::equal
> calling?
This is the reason why there is a type bound on the class that should
result in a composition error when the equal
HaloO Jonathan,
you wrote:
> Of course, you then run into a problem if the class _doesn't_ redefine
> method equal; if it doesn't, then what is GenPointMixin::equal
> calling?
This is the reason why there is a type bound on the class that should
result in a composition error when the equal metho
TSa wrote:
Jonathan Lang wrote:
> TSa wrote:
>> This is exactly what I don't want. Such an equal method needs to be
>> written in each and every class the role GenPoint is composed into.
>
> No, it doesn't. It only needs to be written in those classes where
> the 'equal' method is supposed to be
HaloO,
Jonathan Lang wrote:
class GenSquare does GenPoint does GenEqual
{
has Int $.side;
method equal ( GenSquare $p --> Bool )
{
return $self.GenPoint::equal($p) and $self.side == $p.side;
}
}
This is exactly what I don't want. Such an equal method needs to be
written in each an
TSa wrote:
HaloO,
Jonathan Lang wrote:
> Still not following. Can you give an example?
The example in the original post contains a class GenSquare that
has got an equal method that checks the sides of the self square
and the incoming argument square. The GenPointMixin role provides
an equal me
HaloO,
Jonathan Lang wrote:
Still not following. Can you give an example?
The example in the original post contains a class GenSquare that
has got an equal method that checks the sides of the self square
and the incoming argument square. The GenPointMixin role provides
an equal method that co
TSa wrote:
Jonathan Lang wrote:
> What do you mean by "uncomposed class"?
The self always refers to the object as instance of the composed
class. Methods are therefore resolving to the outcome of the
composition process. But super in a role refers to methods from
the class definition even when t
HaloO,
Jonathan Lang wrote:
So if I'm reading this right, a class that does both A and B should be
"lower" in the partial ordering than a class that does just one or the
other. And if A does B, then you'll never have a class that does just
A without also doing B, which trims out a few possible
HaloO,
Jonathan Lang wrote:
What do you mean by "uncomposed class"?
The self always refers to the object as instance of the composed
class. Methods are therefore resolving to the outcome of the
composition process. But super in a role refers to methods from
the class definition even when the f
TSa wrote:
Jonathan Lang 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?
In addition to Matt Fowles explanation I would like to
give the following example lattice build
Brad Bowman wrote:
TSa wrote:
> TSa wrote:
>> Note that the superclass interface of roles should be mostly inferred
>> from the usage of next METHOD. As such it is a useful guidance for
>> error reports in the class composition process.
>
> Actually 'next METHOD' doesn't catch all superclass inte
TSa wrote:
TSa wrote:
Note that the superclass interface of roles should be mostly inferred
from the usage of next METHOD. As such it is a useful guidance for
error reports in the class composition process.
Actually 'next METHOD' doesn't catch all superclass interface issues.
There is the simp
HaloO,
TSa wrote:
Note that A = (A|B) & (A|C) is the intersection type of A|B and A|C.
Note further that A|B is a subtype of A and B written A|B <: A and
A|B <: B and so on. Usually the A|B|C is called Bottom or some such.
I think it is the Whatever type of Perl6. It is the glb (greatest lower
b
HaloO,
Stevan Little wrote:
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.
I don't get that. The type system would give compile time errors.
The current spec means that in case of
HaloO,
TSa wrote:
Note that the superclass interface of roles should be mostly inferred
from the usage of next METHOD. As such it is a useful guidance for
error reports in the class composition process.
Actually 'next METHOD' doesn't catch all superclass interface issues.
There is the simple c
HaloO,
Jonathan Lang 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?
In addition to Matt Fowles explanation I would like to
give the following example lattice build from the r
HaloO,
Stevan Little wrote:
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.
The bloa
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 shi
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
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 mome
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 ge
TSa wrote:
I'm not familiar with the next METHOD syntax.
It's simple: if a multi method says "next METHOD;" then execution of
the current method gets aborted, and the next MMD candidate is tried;
it uses the same parameters that the current method used, and it
returns its value to the current m
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 an
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 parameter
HaloO,
Brad Bowman wrote:
Sam Vilain wrote:
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.
Sure. The point is, how does a role designer mix in the x and y
coordinate attributes *and* augment the no
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
On Monday 02 October 2006 08:58, Jonathan Lang wrote:
> 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 questi
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
Brad Bowman wrote:
Hi,
Did you mean to go off list?
No, I didn't.
Jonathan Lang wrote:
> Brad Bowman wrote:
>> Does the "class GenSquare does GenEqual does GenPointMixin" line imply
>> an ordering of class composition?
>
> No. This was a conscious design decision: the order in which you
> c
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 ac
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 th
TSa wrote:
> HaloO,
>
> 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 th
HaloO,
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
t
HaloO,
After re-reading about the typing of mixins in
http://www.jot.fm/issues/issue_2004_11/column1
I wonder how the example would look like in Perl6.
Here is what I think it could look like:
role GenEqual
{
method equal( : GenEqual $ --> Bool ) {...}
}
role GenPointMixin
{
has Int $.x;
60 matches
Mail list logo
