Juerd wrote:
Juerd skribis 2005-05-14 17:23 (+0200):
Markus Laire skribis 2005-05-14 18:07 (+0300):
[>>+^=<<] (@a, @b, @c)
These arrays flatten first (otherwise [+] @foo could never calculate the
sum of the elements), so imagine that you have
$foo, $bar, $baz, $quux, $xyzzy
to let >>+^=<< op
> On 15/05/05 22:48 +0100, Matthew Walton wrote:
> I don't think that is what Rob is saying at all.
It wasn't aimed entirely at Rob. I have a bad habit on mailing lists of
vaguely replying to the entire thread without remembering who said what
and being too lazy to check.
> My read:
>
>.method
Damian Conway skribis 2005-05-16 10:33 (+1000):
> This missing design rationale here is that the colon acts as part of the
> unary operator:
> ./unary public-method-call-on-invocant
> .:unary private-method-call-on-invocant
> So the rule is:
> One-character operator --> call on
On Sun, 2005-05-15 at 19:18 +0200, Juerd wrote:
> Now:
> Declaration ExplicitImplicit $_ $?SELF
> has $.var | $obj.var \ .var \ ./var \
> has $:var | $obj.:var \ .:var \ ./:var \
>
> Consistent:
> has $.var \ $obj.var \
I am currently failing to see the need for a distinction between $.
and $: . The only difference is in whether accessors are *generated*;
the attribute access itself is no different. If you want to refactor
and turn your auto-accessor into a custom one, you have to[1] go
replace $. with $: everyw
On Sun, 2005-05-15 at 13:33 -0500, Rod Adams wrote:
> Aaron Sherman wrote:
>
> >In reviewing S29 as it stands now, I see that many builtins both receive
> >and return boxed basic types.
> My thoughts on writing it were:
>
> The boxed version is the specification, in that the language must
> sup
Aaron Sherman skribis 2005-05-16 5:54 (-0400):
> On Sun, 2005-05-15 at 19:18 +0200, Juerd wrote:
> > Now:
> > Declaration ExplicitImplicit $_ $?SELF
> > has $.var | $obj.var \ .var \ ./var \
> > has $:var | $obj.:var \ .:var \ ./:var \
On Mon, 2005-05-16 at 04:02 -0600, Luke Palmer wrote:
> I am currently failing to see the need for a distinction between $.
> and $: . The only difference is in whether accessors are *generated*;
Not at all! There are numerous differences as described in A12:
* The attribute gets a "privat
On Mon, 2005-05-16 at 12:23 +0200, Juerd wrote:
> Aaron Sherman skribis 2005-05-16 5:54 (-0400):
> > I'm not sure I see that you changed anything
[...]
> Okay, let's try it differently, then:
[...something that looks like braille...]
And now, you've s/[\$\w]+//g; what point are you making, Jue
On Mon, 2005-05-16 at 09:08, Aaron Sherman wrote:
> Well, there's the problem. If you see those as the same symbol, then of
> course this is deeply confusing.
I just want to make the point that the "you" in that sentence is "you,
the user of Perl", not "you, Juerd". Obviously, you are not confuse
On Mon, May 16, 2005 at 10:18:47AM +0300, Markus Laire wrote:
: As S09 says that:
:
: At the statement level, a semicolon terminates the current
: expression. Within any kind of bracketing construct, semicolon
: notionally produces a list of lists, the interpretation of which
: dep
Hi,
class Foo {
submethod BUILD() {
say 42;
}
}
class Bar is Foo {
submethod BUILD() {
say 23;
}
}
my Bar $bar .= new;
I suppose this will output:
42
23
S12 says that "submethod[s] [are] called only when a method call is
dispatched
Hi,
are Roles allowed to contain submethods and does especially the BUILD
submethod
work as I presume in the following code?
class IRC::Bot {
has Array %:handler;
method add_handler(Str $event, Code $callback) {
push %:handler{$event}: $callback;
}
...;
}
On Mon, May 16, 2005 at 02:59:11PM +, Ingo Blechschmidt wrote:
: Hi,
:
: class Foo {
: submethod BUILD() {
: say 42;
: }
: }
:
: class Bar is Foo {
: submethod BUILD() {
: say 23;
: }
: }
:
: my Bar $bar .= new;
:
: I suppose this will o
On Mon, 2005-05-16 at 07:21, Aaron Sherman wrote:
> * %$obj notation includes private attributes when inside, but not
> when outside the class
This bit was new to me this morning, when I looked it up, and I'd like
to delve into a bit more.
If the idea is to provide a hash-like thin
On Mon, May 16, 2005 at 03:10:10PM +, Ingo Blechschmidt wrote:
: my MyBot $bot .= new;
: # Are IRC::Bot::JoinOnInvite::BUILD and
: # IRC::Bot::SayHelloOnJoin::BUILD called?
Yes, role BUILD submethods are magically composed into the class's
BUILD method somehow (or at least called at t
This evaluates to 1 in Perl 5:
not 4,3,2,1,0;
Namely, the "not" listOp is taking the last of a variadic, non-slurpy
argument list, boolify it, and return its negation.
What is the Perl 6 signature that correspond to this behaviour?
Also, is this still sane for Perl 6's ¬?
Thanks,
/Autriju
All~
I feel like people have lost track of one of the initial arguments for
having C< .method == $?SELF.method >. Currently, all of
$.foo
@.foo
%.foo
and their ilk operate on the current invocant, $?SELF. This leads
naturally toward &.foo also refering to $?SELF. But as we all know
the & is o
On Mon, May 16, 2005 at 02:26:02PM -0400, Matt Fowles wrote:
> $.foo
> @.foo
> %.foo
>
> and their ilk operate on the current invocant, $?SELF. This leads
> naturally toward &.foo also refering to $?SELF. But as we all know
> the & is optional on function calls...
I believe you are thinking in
Hi,
wolverian wrote:
> On Mon, May 16, 2005 at 02:26:02PM -0400, Matt Fowles wrote:
>> $.foo
>> @.foo
>> %.foo
>>
>> and their ilk operate on the current invocant, $?SELF. This leads
>> naturally toward &.foo also refering to $?SELF. But as we all know
>> the & is optional on function calls...
On Tue, May 17, 2005 at 01:48:20AM +0800, Autrijus Tang wrote:
: This evaluates to 1 in Perl 5:
:
: not 4,3,2,1,0;
:
: Namely, the "not" listOp is taking the last of a variadic, non-slurpy
: argument list, boolify it, and return its negation.
:
: What is the Perl 6 signature that correspond
On Mon, May 16, 2005 at 12:49:13PM -0700, Larry Wall wrote:
> On Tue, May 17, 2005 at 01:48:20AM +0800, Autrijus Tang wrote:
> : This evaluates to 1 in Perl 5:
> :
> : not 4,3,2,1,0;
> :
> : Namely, the "not" listOp is taking the last of a variadic, non-slurpy
> : argument list, boolify it,
On Tue, May 17, 2005 at 05:32:27AM +0800, Autrijus Tang wrote:
: Ok, but I'm still not too sure about what signature will Perl 6's ¬
: have, that can impose singular context on each of its argument (so that
: not(@foo) won't flatten), but still accept an unlimited number of
: arguments. It's somet
Ingo Blechschmidt skribis 2005-05-16 21:28 (+0200):
> yes, but with parens, it *is* a call:
> sub foo(...) {...}
> say &foo(...); # Calls &foo
> say foo(...); # Calls &foo
> say &foo; # "CODE(0x)" or somesuch
Only because there's an implicit "." there. This is like
On 5/16/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> Yes, role BUILD submethods are magically composed into the class's
> BUILD method somehow (or at least called at the appropriate time).
Could this be a feature of all submethods, not just BUILD? (DESTROY,
for instance, would need it too...)
--
On Mon, May 16, 2005 at 04:06:15PM -0700, Larry Wall wrote:
> That's
>
> sub not (*args is context(Scalar))
>
> or whatever we end up calling the Any/Scalar type.
How about is context(Item) versus is context(Slurpy). :)
Also, shouldn't the *args there be [EMAIL PROTECTED] Is it really okay
26 matches
Mail list logo
