Re: Ignoring parameters
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 :)
{
my foo $f;
... # use $f
}
--
TSa (Thomas Sandla)
Re: Ignoring parameters
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. I understand why the one I wrote above is
incorrect -- silly me. But I'm having trouble with the syntactical
parsing of the parameter list of the second, and I can't find any
references or similar cases in S12/A12/S06/A06. Is '::' acting as a
sigil here?
More to the point, I'm having trouble meshing this with the rules for
parameters listed in A06 (fully recognizing that there may be
correcter forms of A06-- I'm just trying to find what the correcter
form is ... :-). From A06, with an updated rule sigil for
private attributes and pod
Here's what an individual parameter looks like:
rule parameter :w {
[ type? zone? variable trait* defval?
| \[ signature \] # treat single array ref as an arg list
]
}
rule zone { [?*+] }
rule variable { sigil name [ \( siglet \) ]? }
rule sigil { [EMAIL PROTECTED]] [*.:?^=]? }
I'm missing something fundamental in getting
method greet(FooClass ::class:) { say Hello!; }
to parse.
Pm
Re: Ignoring parameters
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 parameter
allowing you to call func without the . The :: is a real sigil in that
regard, and function parameters are real declarations.
Larry
Re: Ignoring parameters
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 would, I suppose, have to parse :::foo as a private :foo package name.
Larry
Re: Ignoring parameters
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]] [*.:?^=]? }
rule sigil { [ [EMAIL PROTECTED]] | '::' ] [*.:?^=]? }
which would, I suppose, have to parse :::foo as a private :foo package name.
Works for me (for now), thanks!
Pm
Re: Ignoring parameters
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 slurpy [EMAIL PROTECTED] argument, emulating the Perl 5 mechanisms.)
Something like:
# Do something then proceed with call as usual
method foo ([EMAIL PROTECTED])
{
./do_something_new(123, 'abc');
./SUPER::foo(@args);
}
# Pull off some args, do something, then proceed with call as usual
method foo ()
{
./do_something_else(val = delete %_xyz);
./SUPER::foo(%_);
}
All methods get a slurpy %_ unless you declare your own. But you probably
want to avoid super semantics and write that:
method foo ()
{
./do_something_else(val = %_xyz);
next;
}
I've also taken the liberty of deleting your delete, on the assumption
that your next method might want to see the same argument and do
something else with it. A set of next methods need a consistent
parameter namespace in any event, so there's no harm in leaving the
parameter in %_, and some performance benefit in not doing something
better performed by GC (we hope).
Larry
Re: Ignoring parameters
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? (i.e., Without forcing all methods to have a
: single slurpy [EMAIL PROTECTED] argument, emulating the Perl 5 mechanisms.)
Something like:
# Do something then proceed with call as usual
method foo ([EMAIL PROTECTED])
{
./do_something_new(123, 'abc');
./SUPER::foo(@args);
}
Hm, but will that still catch cases where I call foo() with incorrect
arguments? I like the idea of method signatures that help catch incorrect
calls, but I don't quite understand how I can be ignorant of the super
method's signature while (essentially) delegating to it after doing my
thing. Looking at the above, I wonder if my overridden foo() would
basically remove the benefit signatures, allowing me to call it any which
way. (Whereas the superclass foo() might have a really strict signature and
catch any bad calls.)
(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 .)
But you probably want to avoid super semantics and write that:
method foo ()
{
./do_something_else(val = %_xyz);
next;
}
I've also taken the liberty of deleting your delete, on the assumption
that your next method might want to see the same argument and do
something else with it. A set of next methods need a consistent
parameter namespace in any event, so there's no harm in leaving the
parameter in %_, and some performance benefit in not doing something
better performed by GC (we hope).
What do you mean by a consistent parameter namespace? Surely they don't
need to have the same signature(?) That's kind of the point of my second
example: to override a method, add stuff to the signature, act on the new
params, and then delegate the rest to the superclass, calling it as if the
subclass's added params were never there. That's why I deleted the param
from the hash in the Perl 5 example.
In Perl 6, I'd expect the superclass to puke at runtime if I try to pass it
a parameter that's not in its signature. I thought you had to explicitly
slurp up any other args in your signatures, but I guess I misremembered.
Anyway, I guess I'm just trying to have my cake and eat it too. I want Perl
5's ability to transparently pass any remaining/all args to a superclass
without having to know what kind of args the superclass expects, but I
*also* want to get all of the benefits of strict method signature checking,
even in my subclass method. So...
class MySubClass; # a subclass of MyClass
method foo(MyClass::foo's signature, custom args, if any)
{
# do stuff with custom args, removing them when done
# call MyClass::foo with the remaining args
}
...all without ever knowing or caring what MyClass::foo's signature actually
is, of course. Maybe I'm asking for too much? (Or maybe I just have to
wait for Damian to come up with some clever technique to do it... ;)
-John
Re: Ignoring parameters
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 method on the current invocant. The point being that methods no longer topicalize their invocant. So you need to use ./ instead of . to call methods on an implicit invocant. Damian
Re: Ignoring parameters
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 declare a lexical C$_ but leave it undefined. So, methods and submethods no longer bind their first argument to C$_? Then do we need this statement at all? (I'm suspecting that rules won't need it, leaving just macros and pointy subs.) There are other places in A06 that discuss methods, submethods, and multimethods binding their first arguments to $_ -- I'll see about putting [Update:...] notes in there for each of those. I'll also come up with some patches to S12 for the ./ syntax. Pm
Re: Ignoring parameters
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 current topic. Unary ./ calls a specified method on the current invocant. The point being that methods no longer topicalize their invocant. So you need to use ./ instead of . to call methods on an implicit invocant. Er, is it true that methods don't topicalize the invocant nowadays? 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 ./foo() are the same... --abhijit Damian Abhijit Mahabal http://www.cs.indiana.edu/~amahabal/
Re: Ignoring parameters
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 current topic. Unary ./ calls a specified method on the current invocant. The point being that methods no longer topicalize their invocant. So you need to use ./ instead of . to call methods on an implicit invocant. 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. Was that intentional? Was this syntax discussed on a mailing list or elsewhere? I really liked plain old .foo(), but I guess I'll just use explicit invocants and look like an old fuddy duddy... :) (also, at least it's not /. shudder ;) -John
Re: Ignoring parameters
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 ./foo() are the same... I think that would be a really bad idea. It's a gilt-edged invitation for errors to creep in as calls to .meth() silently change semantics when code is refactored. The whole point of ./ is to have one unambiguous way of calling methods on an implicit invocant. I'm arguing that that one umambiguous way should be the *only* way. Having an unambiguous way *and* an ambiguous way seems like poor design. Damian
Re: Ignoring parameters
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 discussed on a mailing list or elsewhere? Both on the mailing list and within @Larry. I really liked plain old .foo(), We felt the ambiguity and change-of-semantics within topicalizers made it unacceptable. but I guess I'll just use explicit invocants and look like an old fuddy duddy... :) That's fine, Gramps! ;-) (also, at least it's not /. shudder ;) grin Damian
Ignoring parameters
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 issue a warning in such a case.
The same problem exists with methods in classes fulfilling a role,
but which want to ignore a parameter in a required method.
What do you say about this proposed syntax?
method greet(Class undef: ) { ... }
# the interface calls for a floor as 1st arg
method bereaucracy(Int undef, Int $office_number) { ... }
I'm not sure how this works for named fields, but for positional ones
it should do well, and is similar to ($a, undef, $c) = LIST syntax.
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
Re: Ignoring parameters
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, 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 issue a warning in such a case.
I don't think that the compiler should issue a warning in the case of
unused parameters. Since the names of parameters mean something more
than just how the method refers to them--they specify the names of
named parameters--it could be useful to accept a parameter that is not
used, in anticipation of them eventually being used. The unused
parameter warning has never caught an error that undeclared
variable hasn't for me (as long as I name things well), and usually
is just a cue to bring out my UNUSED fingers.
The same problem exists with methods in classes fulfilling a role,
but which want to ignore a parameter in a required method.
What do you say about this proposed syntax?
method greet(Class undef: ) { ... }
Or we could finally take an idea from C++, one that I don't think is
so unreasonable:
method greet(Class:) {...}
Since there is no :: on the front of Class, it can't be mistaken for a
parameter. That does bring up the question of what happens if you
want to specify an indirect type as the type of a parameter. Maybe we
just disallow that...
Luke
Re: Ignoring parameters
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 methods...
What do you think is the right way to specify them?
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
Re: Ignoring parameters
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 class methods...
What do you think is the right way to specify them?
I certainly can't speak for Luke, but I think the right way to specify class
methods is:
method greet(FooClass ::class:) {
say Hello, FooClass!;
}
And I think that subs and methods *should* complain about all unused
non-optional parameters *except* invocants.
Damian
Re: Ignoring parameters
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 calls the superclass
method of the same name, passing all arguments. Or sometimes I pull off an
argument or two that only make sense to my method, leaving the rest for the
superclass method. This is all easy when args are just items in the @_
array.
Here are some Perl 5 examples:
# Do something then proceed with call as usual
sub foo
{
$_[0]-do_something_new(123, 'abc');
shift-SUPER::foo(@_);
}
# Pull off some args, do something, then proceed with call as usual
sub foo
{
my($self, %args) = @_;
$self-do_something_else(val = delete $args{'xyz'});
$self-SUPER::foo(%args);
}
Note that in both cases my foo() method doesn't know or care what
SUPER::foo()'s arguments are.
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 slurpy [EMAIL PROTECTED] argument, emulating the Perl 5 mechanisms.)
-John
Re: Ignoring parameters
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 from the fact that I don't think this is the right way to
specify class methods...
What do you think is the right way to specify them?
I certainly can't speak for Luke, but I think the right way to specify
class methods is:
method greet(FooClass ::class:) {
say Hello, FooClass!;
}
In the interest of keeping the design documents up-to-date, A12 says:
To declare an ordinary class method, such as a constructor, you say
something like:
method new (Class $class: [EMAIL PROTECTED]) { ... }
Such a method may only be called with an invocant that isa CClass,
that is, an object of type CClass, or derived from type CClass.
S12 says:
Class methods are just methods that can take a class as their invocant.
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!; }
or
method greet(FooClass $class:) { say Hello!; }
Are the design documents out of date in this regard? If so, can
someone provide a patch, if not, can someone confirm that the design
documents are correct? (I just happened to be looking at class methods
this past week, which is why I was a little surprised by Luke and
Damian's answers... :-)
Pm
Re: Ignoring parameters
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 Hello!; }
No. That needs to be:
method greet(FooClass ::class:) { say Hello!; }
(as implied by takes a class as its invocant in S12).
^
Are the design documents out of date in this regard? If so, can
someone provide a patch, if not, can someone confirm that the design
documents are correct? (I just happened to be looking at class methods
this past week, which is why I was a little surprised by Luke and
Damian's answers... :-)
Both documents are correct, but S12 is correcter (as you would expect).
Damian
