John Siracusa wrote:
Wow, that..er...how did I miss that? It looks a lot like running an
executable in the current dir instead of letting the shell search its path.
That's the mnemonic, yes. Call this functionality relative to the current
"location" (i.e. invocant).
Was this syntax discu
Abhijit Mahabal asked:
Er, is it true that methods don't topicalize the invocant nowadays?
If it's not true, it darn well ought to be!
I had thought that they do and one needs the ./ to still talk about the
invocant if some inner loop stole the $_, and until such stealing occurs
.foo() and
On 6/17/05 6:18 PM, Damian Conway wrote:
> John Siracusa wrote:
>> (BTW, I'm not sure where those "./" thingies came from, but it's what GMail
>> showed in your message. I'm assuming it should just be ".")
>
> No. There's now also a unary ./ operator in Perl 6.
>
> Unary . calls a specified meth
On Sat, 18 Jun 2005, Damian Conway wrote:
John Siracusa wrote:
(BTW, I'm not sure where those "./" thingies came from, but it's what
GMail
showed in your message. I'm assuming it should just be ".")
No. There's now also a unary ./ operator in Perl 6.
Unary . calls a specified method on
On Sat, Jun 18, 2005 at 08:18:17AM +1000, Damian Conway wrote:
> The point being that methods no longer topicalize their invocant.
To update the design docs, A06 currently says:
Methods, submethods, macros, rules, and pointy subs all
bind their first argument to C<$_>; ordinary subs decl
John Siracusa wrote:
(BTW, I'm not sure where those "./" thingies came from, but it's what GMail
showed in your message. I'm assuming it should just be ".")
No. There's now also a unary ./ operator in Perl 6.
Unary . calls a specified method on the current topic.
Unary ./ calls a specified m
On 6/17/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 16, 2005 at 05:18:51PM -0400, John Siracusa wrote:
> : Now in Perl 6 I'll want to use fancy named parameters and so on, but I don't
> : want to lose the abilities described above. How would those examples look
> : in "native" Perl 6 c
On Thu, Jun 16, 2005 at 05:18:51PM -0400, John Siracusa wrote:
: Now in Perl 6 I'll want to use fancy named parameters and so on, but I don't
: want to lose the abilities described above. How would those examples look
: in "native" Perl 6 code? (i.e., Without forcing all methods to have a
: singl
On Fri, Jun 17, 2005 at 11:56:11AM -0700, Larry Wall wrote:
> On Fri, Jun 17, 2005 at 09:03:57AM -0500, Patrick R. Michaud wrote:
> : Is '::' acting as a sigil here?
>
> Yes.
>
> : rule variable { [ \( \) ]? }
> : rule sigil { <[EMAIL PROTECTED]&]> <[*.:?^=]>? }
>
> r
On Fri, Jun 17, 2005 at 09:03:57AM -0500, Patrick R. Michaud wrote:
: Is '::' acting as a sigil here?
Yes.
: rule variable { [ \( \) ]? }
: rule sigil { <[EMAIL PROTECTED]&]> <[*.:?^=]>? }
rule sigil { [ <[EMAIL PROTECTED]&]> | <'::'> ] <[*.:?^=]>? }
which would,
On Fri, Jun 17, 2005 at 09:19:17AM +0200, "TSa (Thomas Sandlaß)" wrote:
: Ohh, does that mean that ::class can be used as a type
: inside the body? E.g.
:
: method template ( FooClass ::foo :)
: {
:my foo $f;
:
:... # use $f
: }
Certainly. It's exactly the same situation as a &func form
On Fri, Jun 17, 2005 at 08:13:55AM +1000, Damian Conway wrote:
> Patrick wrote:
> >method greet(FooClass $class:) { say "Hello!"; }
>
> No. That needs to be:
>
> method greet(FooClass ::class:) { say "Hello!"; }
>
> (as implied by "takes a class as its invocant" in S12).
Okay, I'm a b
Damian Conway wrote:
No. That needs to be:
method greet(FooClass ::class:) { say "Hello!"; }
(as implied by "takes a class as its invocant" in S12).
^
Ohh, does that mean that ::class can be used as a type
inside the body? E.g.
method template ( FooClass ::f
Patrick wrote:
Somehow I read these as though the original poster was correct --
i.e., one creates a class method for FooClass as either
method greet(Class $class:) { say "Hello!"; }
Yes. That will work, but it's not the recommended solution.
or
method greet(FooClass $class:) { sa
On Fri, Jun 17, 2005 at 07:05:11AM +1000, Damian Conway wrote:
> Gaal Yahas wrote:
> >On Thu, Jun 16, 2005 at 01:26:31PM -0600, Luke Palmer wrote:
> >>>Say I have a class method in FooClass, callable as FooClass.greet():
> >>>method greet(Class $class: ) {
> >>> say "Hello, FooClass!";
>
On 6/16/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> And I think that subs and methods *should* complain about all unused
> non-optional parameters *except* invocants.
This brings up something I've been thinking about. I sometimes write a
method in Perl 5 that does something or other and then c
Gaal Yahas wrote:
On Thu, Jun 16, 2005 at 01:26:31PM -0600, Luke Palmer wrote:
Say I have a class method in FooClass, callable as FooClass.greet():
method greet(Class $class: ) {
say "Hello, FooClass!";
}
Aside from the fact that I don't think this is the right way to
specify
On Thu, Jun 16, 2005 at 01:26:31PM -0600, Luke Palmer wrote:
> > Say I have a class method in FooClass, callable as FooClass.greet():
> >
> > method greet(Class $class: ) {
> > say "Hello, FooClass!";
> > }
>
> Aside from the fact that I don't think this is the right way to
> sp
On 6/16/05, Gaal Yahas <[EMAIL PROTECTED]> wrote:
> Say I have a class method in FooClass, callable as FooClass.greet():
>
> method greet(Class $class: ) {
> say "Hello, FooClass!";
> }
Aside from the fact that I don't think this is the right way to
specify class methods...
> A
Say I have a class method in FooClass, callable as FooClass.greet():
method greet(Class $class: ) {
say "Hello, FooClass!";
}
AFAIK, this is the only signature that would work for making &greet a
class method; but note that I'm not using $class, and I'd expect the
compiler to is
20 matches
Mail list logo
