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
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #40511]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40511
Hi,
This patch removes the deprecated fetchmethod opcode from various ops
files,
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #40503]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40503
Hi,
This patch removes the paragraph in DEPRECATED.pod mentioning that the
.imc
What's a C++ comment? If you mean //...\n comments, those are legal
in ANSI-99 C (and the syntax goes back to BCPL). If the coding
standard specifies multiline-style comments only, fine, but please
don't use misleading terminology.
-- Forwarded message --
From: via RT Paul
[EMAIL PROTECTED] wrote:
What's a C++ comment? If you mean //...\n comments, those are legal
in ANSI-99 C
Parrot is using ANSI-98 C, I believe. And //\N+\n comments are not legal
in that.
Jonathan
On 10/11/06, via RT Paul Cochrane [EMAIL PROTECTED] wrote:
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40503
This patch removes the paragraph in DEPRECATED.pod mentioning that the
.imc file extension is deprecated since there are no longer any .imc
files in Parrot (having all been
i'm not 100% sure this is the right thing to do, either. the most
recent version of perl 6 and parrot essentials still makes reference
to '.imc' files. with this paragraph in deprecated.pod, there's
something to grep for that might help readers make the transition to
'.pir'.
True. Thought it
On 10/11/06, Jonathan Worthington [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
What's a C++ comment? If you mean //...\n comments, those are legal
in ANSI-99 C
Parrot is using ANSI-98 C, I believe. And //\N+\n comments are not legal
in that.
jonathan ment C89 of course. some compilers
On 10/11/06, Paul Cochrane [EMAIL PROTECTED] wrote:
i'm not 100% sure this is the right thing to do, either. the most
recent version of perl 6 and parrot essentials still makes reference
to '.imc' files. with this paragraph in deprecated.pod, there's
something to grep for that might help
@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
Jerry,
1) the patch leaves trailing spaces after the closing brackets (this
isn't a coding standard (yet) but is a pet peeve of mine. if it were
this alone, i'd modify the patch myself and apply.
I can add a test for this to t/codingstd/cuddled_else.t if you want.
2) many of the source files
thanks, applied as r14897.
~jerry
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
# New Ticket Created by Jerry Gay
# Please include the string: [perl #40513]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40513
*.l and *.y are c files, and must meet the coding standards for this filetype.
~jerry
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
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
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
--- 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
On 10/11/06, Bernhard Schmalhofer via RT
[EMAIL PROTECTED] wrote:
On Mi. 11. Okt. 2006, 08:10:45, [EMAIL PROTECTED] wrote:
Yes, I got exacly the same output from r14895. Actually, this patch
was already applied by Bernhard in r14870, which explains why the
effected files list looks
On Wednesday 11 October 2006 01:19, Paul Cochrane wrote:
This is because I was too fast with the Send button, and forgot to
attach the patch. Apologies for the doubled-up email.
Nit: you can reply to a previous RT mail and attach the patch there. That
saves a duplicate bug report that
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
Jerry Gay (via RT) wrote:
*.l and *.y are c files, and must meet the coding standards for this filetype.
~jerry
By this filetype I assume you mean the C standard. Although these
files contain C code and that code should be written to the C standard,
they are not C files. Each should have its
Author: allison
Date: Wed Oct 11 13:37:08 2006
New Revision: 14903
Modified:
trunk/docs/pdds/clip/pdd25_threads.pod
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
Log:
[EMAIL PROTECTED]: allison | 2006-10-11 13:18:42 -0700
Partial update of Threads PDD
I have rewritten the grammar. There are some problems though.
- I don't know how to express thinks like: an identifier is
[a..zA..Z_$]*, but not a keyword. Something like: rule identifier
{!keyword[a..zA..Z_$]*} seems not to allow identifiers that have
keywords as prefix.
- I couldn't make
Am Mittwoch, 11. Oktober 2006 22:37 schrieb [EMAIL PROTECTED]:
Log:
[EMAIL PROTECTED]: allison | 2006-10-11 13:18:42 -0700
Partial update of Threads PDD with collected wisdom from prior discussion.
I know the pdd is partial, but don't forget STM, which is
a) implemented and
b) solves a lot
Hi all,
Who's looking after the Cage Cleaners these days? I've noticed a few people
applying the patches, but it would be nice to have someone making sure we
don't miss anything.
-- c
On Wed, Oct 11, 2006 at 10:56:39PM +0200, Mehmet Yavuz Selim Soyturk wrote:
I have rewritten the grammar. There are some problems though.
- I don't know how to express thinks like: an identifier is
[a..zA..Z_$]*, but not a keyword. Something like: rule identifier
{!keyword[a..zA..Z_$]*}
On Oct 11, 2006, at 4:32 PM, chromatic wrote:
Who's looking after the Cage Cleaners these days? I've noticed a
few people
applying the patches, but it would be nice to have someone making
sure we
don't miss anything.
I should be, but I've clearly been very lax.
Would someone like to
i'd volunteer but what skills/duties are involved?
hal
chicago
On Oct 11, 2006, at 4:34 PM, Andy Lester wrote:
On Oct 11, 2006, at 4:32 PM, chromatic wrote:
Who's looking after the Cage Cleaners these days? I've noticed a
few people
applying the patches, but it would be nice to have
On Tue, Oct 10, 2006 at 01:31:59PM -0700, Ovid wrote:
Hi all,
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 applied to a class at runtime, a instance of that
在 Oct 12, 2006 5:43 AM 時，Tim Bunce 寫到：
On Tue, Oct 10, 2006 at 01:31:59PM -0700, Ovid wrote:
Hi all,
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 applied to a
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
42 matches
Mail list logo
