HaloO,
On Sunday, 25. October 2009 01:38:21 Martin D Kealey wrote:
Sounds like going back to static typing -- which does sometimes have some
advantages.
Well, you can also consider it dynamic. The important point is
that it is a constraint on allowed types e.g. in the sig of a sub
or on a
HaloO,
On Thursday, 22. October 2009 20:58:15 I wrote:
The class Dogwood however might be written as
class Dogwood does Dog[Dogwood:] does Wood[Dogwood:]
{
method Dog {...}
method Wood {...}
method bark {...}
}
On #perl there was the question if any type
On Wed, 21 Oct 2009, Ben Morrow wrote:
The most important detail here is that the *class* gets to pick which
imported methods need to be wrapped.
[but]
What this doesn't fix is that some other code (outside the class) will be
expecting C::x to have T1::x semantics, and some will be expecting
Quoth tho...@sandlass.de (TSa (Thomas =?utf-8?q?Sandla=C3=9F?=)):
Here is a direct syntax for the freeze feature of the paper:
class C does T1 does T2
{
freeze T1::x for foo;
freeze T2::x for bar;
method x {...} # for all other methods
}
The implementation is
HaloO,
Ben Morrow wrote:
Isn't this just sugar for something like
Yes it is. My intent was to lighten the burden. I think we can agree
that Ovid's problem can be solved by means of the current spec and
some support syntax could be easily added.
What this doesn't fix is that some other code
HaloO,
On Thursday, 22. October 2009 18:31:16 I wrote:
The invocant slot of the role signature is sort of implied in the spec
already! I also like this because a type in Perl 6 is then always
written as SomeRole[SomeClass:]. Classes without explicit roles are
Any[SomeClass:] and untyped is
- Original Message
From: TSa (Thomas Sandlaß) tho...@sandlass.de
So what the OP wants to do is declare a method that is available on
all those invocants - and only those invocatnts - which do all of
roles X, Y, and Z. Granted, you can declare a new role XandYandZ
that does
On Wed, Oct 21, 2009 at 3:47 AM, Ovid
publiustemp-perl6langua...@yahoo.com wrote:
I was asking the special case where:
1. A class consumes two (or more) roles
2. Each roles provides a method with an identical signature
3. The methods are not equivalent and neither role can rely on the other's
Jonathan Worthington wrote:
Ovid wrote:
I was asking the special case where:
1. A class consumes two (or more) roles
2. Each roles provides a method with an identical signature
3. The methods are not equivalent and neither role can rely on the other's
method
With that, you have roles
HaloO,
Jon Lang wrote:
I have some more thoughts on this; but I'm on a time crunch at the
moment, and would really like to get some feedback on the above before
proceeding further: have I missed anything in my reasoning?
I fully understand what you mean, I hope. But note that all instances
of
TSa wrote:
Jon Lang wrote:
I have some more thoughts on this; but I'm on a time crunch at the
moment, and would really like to get some feedback on the above before
proceeding further: have I missed anything in my reasoning?
I fully understand what you mean, I hope. But note that all
HaloO,
On Wednesday, 21. October 2009 12:40:06 Mark J. Reed wrote:
Rather than disallow the composition, I'd say that any class, role, or
object that does both roles must override the method in question.
The problem that Ovid posed needs to be resolved in the dispatch
tables seen in certain
On Mon, Oct 19, 2009 at 11:47 PM, Jon Lang datawea...@gmail.com wrote:
Because a method is part of a role, and ought to abide by the same
terms by which the role abides. If Logging doesn't do Numeric, it
shouldn't have any methods in it that won't work unless it does.
100% agreed.
So what
On Tue, Oct 20, 2009 at 2:32 PM, Mark J. Reed markjr...@gmail.com wrote:
On Mon, Oct 19, 2009 at 11:47 PM, Jon Lang datawea...@gmail.com wrote:
Because a method is part of a role, and ought to abide by the same
terms by which the role abides. If Logging doesn't do Numeric, it
shouldn't have
On 2009-Oct-20, at 7:55 am, Matthew Walton wrote:
On Tue, Oct 20, 2009 at 2:32 PM, Mark J. Reed markjr...@gmail.com
wrote:
On Mon, Oct 19, 2009 at 11:47 PM, Jon Lang datawea...@gmail.com
wrote:
Because a method is part of a role, and ought to abide by the same
terms by which the role abides.
HaloO,
On Tuesday, 20. October 2009 18:35:36 David Green wrote:
So what the OP wants to do is declare a method that is available on
all those invocants - and only those invocatnts - which do all of
roles X, Y, and Z. Granted, you can declare a new role XandYandZ
that does X, Y, and Z,
On Tue, Oct 20, 2009 at 5:35 PM, David Green david.gr...@telus.net wrote:
I would expect $foo where {$_ ~~ X} and X $foo simply to be different
ways of writing the same thing, but whatever works!
Yes, but the where clause lets you test against multiple types at
once. They don't participate in
In Aiasing methods in CPAN roles, David Green wrote:
Jon Lang wrote:
David Green wrote:
I would expect that role Logging { method log(Numeric $x:) {...} }
means the invocant is really of type Numeric Logging, without Logging
having to do Numeric. On the other hand, I can see that strictly
On 2009-Oct-19, at 5:50 pm, Jon Lang wrote:
In Aiasing methods in CPAN roles, David Green wrote:
I don't want my special log() method to work only for other types
that explicitly do NumLog; I want it to work for any type that
directly does Numeric does Logging.
But if Logging doesn't do
David Green wrote:
Jon Lang wrote:
In Aiasing methods in CPAN roles, David Green wrote:
I don't want my special log() method to work only for other types that
explicitly do NumLog; I want it to work for any type that directly does
Numeric does Logging.
But if Logging doesn't do Numeric,
20 matches
Mail list logo
