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 ::foo
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 bit confused.
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 formal
On Fri, Jun 17, 2005 at 09:03:57AM -0500, Patrick R. Michaud wrote:
: Is '::' acting as a sigil here?
Yes.
: rule variable { sigil name [ \( siglet \) ]? }
: rule sigil { [EMAIL PROTECTED]] [*.:?^=]? }
rule sigil { [ [EMAIL PROTECTED]] | '::' ] [*.:?^=]? }
which
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 { sigil name [ \( siglet \) ]? }
: rule sigil { [EMAIL PROTECTED]] [*.:?^=]? }
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
: single
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 code?
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
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
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 the
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 method on the
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()
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
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
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...
AFAIK,
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 class
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 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
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!;
}
Aside
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:) { say
20 matches
Mail list logo
