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
Hi all,
I posted this to Perl6 users, but I was Warnocked, it was the wrong list, or
both. Here's another stab at it.
In doing a bit of work with traits (roles) in Perl 5
(http://perlmonks.org/?node_id=577477), I've realized some edge cases which
could be problematic.
First, when a role is
HaloO,
Ovid wrote:
Third, http://dev.perl.org/perl6/doc/design/syn/S12.html says:
You can also mixin a precomposed set of roles:
$fido does Sentry | Tricks | TailChasing | Scratch;
Should that be the following?
$fido does Sentry Tricks TailChasing Scratch;
If you follow my
HaloO,
Ovid wrote:
First, when a role is applied to a class at runtime, a instance of
that class in another scope may specifically *not* want that role.
Is there a way of restricting a role to a particular lexical scope
short of applying that role to instances instead of classes?
I think
@larry[0] wrote:
Log:
P5's s[pat][repl] syntax is dead, now use s[pat] = repl
Wow, I really missed this one! That's a pretty big thing to get my head
around. Are embedded closures in the string handled correctly so that:
s:g[\W] = qq{\\{$/}};
Will do what I seem to be expecting it
First, when a role is applied to a class at runtime, a instance of that
class in another scope may specifically *not* want that role. Is there a
way of restricting a role to a particular lexical scope short of applying
that role to instances instead of classes?
Seems like you could use an
On Wed, Oct 11, 2006 at 10:32:13AM -0400, Aaron Sherman wrote:
: @larry[0] wrote:
:
: Log:
: P5's s[pat][repl] syntax is dead, now use s[pat] = repl
:
: Wow, I really missed this one! That's a pretty big thing to get my head
: around. Are embedded closures in the string handled correctly so
HaloO,
with my idea of deriving a type lattice from all role definitions
the problem of subtyping signatures arises. Please help me to think
this through. Consider
role Foo
{
sub blahh(Int, Int) {...}
}
role Bar
{
sub blahh(Str) {...}
}
role Baz does Foo does Bar # Foo|Bar lub
{
# sub
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
This is the dog does bark vs tree does bark problem. You can assume that
the two methods blahh have naything semantically to do with each other at
all. Unless ther is a specif annotation from the programmer creating the Role
union that they are the same you must assume that they are
On 10/11/06, TSa [EMAIL PROTECTED] wrote:
HaloO,
with my idea of deriving a type lattice from all role definitions
the problem of subtyping signatures arises. Please help me to think
this through. Consider
role Foo
{
sub blahh(Int, Int) {...}
}
role Bar
{
sub blahh(Str) {...}
}
role
--- TSa [EMAIL PROTECTED] wrote:
First, when a role is applied to a class at runtime, a instance of
that class in another scope may specifically *not* want that role.
Is there a way of restricting a role to a particular lexical scope
short of applying that role to instances instead of
Jonathan Lang wrote:
The only thing that I'd like to see changed would be to allow a more
flexible syntax for formatting codes - in particular, I'd rather use
something analogous to the 'embedded comments' described in S02,
replacing the leading # with an appropriate capital letter (as defined
While I agree with most of the changes made to the s[]... notation,
there's one oddity that I just spotted:
S05 says:
This is not a normal assigment, since the right side is
evaluated each time the substitution matches (much like the
pseudo-assignment to declarators can happen at strange
On Wed, Oct 11, 2006 at 05:55:45PM -0700, Jonathan Lang wrote:
: While I agree with most of the changes made to the s[]... notation,
: there's one oddity that I just spotted:
:
: S05 says:
: This is not a normal assigment, since the right side is
: evaluated each time the substitution matches
On Wed, Oct 11, 2006 at 06:29:00PM -0700, Larry Wall wrote:
: s:s:g[, (\w+): (.+) ,] = - $key, $val { $key = $val }.(@())
Hmm, that won't work, since @() is a single argument. It'd have to be one of:
s:s:g[, (\w+): (.+) ,] = - [$key, $val] { $key = $val }.(@())
s:s:g[, (\w+): (.+) ,]
In short, nearly every case where I'm looking to use a raw closure
can be handled almost as easily by prefacing it with Cdo (if the
block doesn't take parameters) or Cdo given (if it does). A bit
more wordy than I'd like, but acceptable; it still reads well.
Although I'd recommend pointing this
Dave Whipp wrote:
I'm not a great fan of this concept of reservation when there is no
mechanism for its enforcement (and this is perl...).
What makes you assume there will be no mechanism for enforcement? The standard
Pod parser (of which I have a 95% complete Perl 5 implementation) will
19 matches
Mail list logo
