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 t
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 var
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 expectin
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
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
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 implem
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 m
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
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
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,
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 which cannot be composed. You must
On Wed, Oct 21, 2009 at 3:47 AM, 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
- Original Message
> From: TSa (Thomas Sandlaß)
> > >> 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
On Tue, Oct 20, 2009 at 5:35 PM, David Green 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 multiple dispatch
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
On 2009-Oct-20, at 7:55 am, Matthew Walton wrote:
On Tue, Oct 20, 2009 at 2:32 PM, Mark J. Reed
wrote:
On Mon, Oct 19, 2009 at 11:47 PM, Jon Lang
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
shou
On Tue, Oct 20, 2009 at 2:32 PM, Mark J. Reed wrote:
> On Mon, Oct 19, 2009 at 11:47 PM, Jon Lang 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
On Mon, Oct 19, 2009 at 11:47 PM, Jon Lang 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 the OP wants to do i
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
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
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
21 matches
Mail list logo
