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
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
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
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
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. If you
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
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 { ... }
}
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 ; C] ;
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
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
by
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 composition?
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
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;
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 composition
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 becomes
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
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
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
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,
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
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
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
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 method
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 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;
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
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:
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
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
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
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
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
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 the
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
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 interface
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 from
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
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
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
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
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
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 ship.
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 get the
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 moment, I'll
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
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 parameters
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 and
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
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
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
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 achieve the
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
compose
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
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 question.
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
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 the same
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
57 matches
Mail list logo
