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 f
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 a
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 you'l
# New Ticket Created by "Paul Cochrane"
# Please include the string: [perl #40505]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40505 >
This is because I was too fast with the "Send" button, and forgot to
attach the patch
# New Ticket Created by "Paul Cochrane"
# Please include the string: [perl #40508]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40508 >
Hi,
This patch changes C++ comments found in pmc files to C comments.
Regards,
Pau
# New Ticket Created by "Paul Cochrane"
# Please include the string: [perl #40511]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40511 >
Hi,
This patch removes the deprecated fetchmethod opcode from various ops
files, and
# New Ticket Created by "Paul Cochrane"
# Please include the string: [perl #40507]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40507 >
Hi,
This patch removes occurrences of "cuddled else" in pmc files. I
guess this pat
# New Ticket Created by "Paul Cochrane"
# Please include the string: [perl #40504]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40504 >
Hi,
This patch adds pmc files to the list of files to test in the
C-language coding
# New Ticket Created by "Paul Cochrane"
# Please include the string: [perl #40509]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40509 >
Hi,
This test checks for DOS line endings in C-language files, and I guess
should go
# New Ticket Created by "Paul Cochrane"
# Please include the string: [perl #40510]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40510 >
Hi,
This patch corrects some of the pod in the t/codingstd/c_code_coda.t test.
Rega
# New Ticket Created by "Paul Cochrane"
# Please include the string: [perl #40503]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40503 >
Hi,
This patch removes the paragraph in DEPRECATED.pod mentioning that the
.imc file
# New Ticket Created by "Paul Cochrane"
# Please include the string: [perl #40506]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40506 >
Hi,
This patch removes hard tabs found in .pmc files.
Regards,
Paul
files affecte
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 Coc
Mark,
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.
In my own defence, I was using terminology from pdd0
[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:
# 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 turned
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 w
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 compi
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 h
@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 i
> 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 bl
# New Ticket Created by Jerry Gay
# Please include the string: [perl #40513]
# in the subject line of all future correspondence about this issue.
# 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 t
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 B
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 diff
--- 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 instea
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 dif
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 so
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
b
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
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 . Something like: rule identifier
{<[a..zA..Z_$]>*} seems not to allow identifiers that have
keywords as prefix.
- I couldn't make comments work.
-
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 . Something like: rule identifier
> {<[a..zA..Z_$]>*} seems not t
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 wea
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 someon
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 tha
在 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 class
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 times).
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 (m
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[<,> (\
In short, nearly every case where I'm looking to use a "raw" closure
can be handled almost as easily by prefacing it with C (if the
block doesn't take parameters) or C (if it does). A bit
more wordy than I'd like, but acceptable; it still reads well.
Although I'd recommend pointing this option ou
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
c
--- Audrey Tang <[EMAIL PROTECTED]> wrote:
> > I always thought when a role is applied to a class at runtime you
> > get a new (anonymous) subclass. The original class isn't affected.
>
> Right, that's what usually happens with:
>
> my Dog $fido .= new;
> $fido does Catlike;
Am I miss
51 matches
Mail list logo
