On Wed, Mar 19, 2003 at 12:19:20PM -0800, Michael Lazzaro wrote:
> I think newbies are going to unquestionably try and put the parameters
> in the same order as they expect to see the eventual arguments, and be
> durn confused it doesn't work -- I know I would.
[...]
> Dunno. I'm just one datapoint, but I strongly see the difference
> between (1) and (2) as being a *huge* newbie trap.
Well, I guess I'm another datapoint then.
Although I don't consider myself a wizard by any means, I've been
programming Perl for a long time and I'm very comfortable with it.
I've read A6 a couple of times and been following the discussions on
the list. And, despite all those advantages, I _still_ don't really
grok the proposed signature stuff (it gets a little clearer every time
I read it, but it's still awfully muddy). I hadn't even recognized
the trap that we are discussing until this thread came up.
I think people just coming to Perl are going to be extremely baffled
and frustrated by the signature syntax and semantics. This is going
to promote one of two reactions: they will leave and go to
Python/Ruby/whatever, or they will never use signatures.
I'm still waiting for the Exegesis...I recognize that the Apocalpsi
are hard simply because they are definitive and must cover every edge
case. Possibly, with some day-to-day examples and down-to-earth
tutorial materials available, all of this will become simple; that has
happened for me before with prior Apocalpsi.
However, even if it ends up being clarified by the Exegesis, the
signature syntax/semantics ARE complex. In order to justify that
complexity, they need to provide a tremendous advantage; I'm simply
not sure that the advantages they provide are worth the complexity.
In order to make it worthwhile (IMO), it would need to be very easy to
use, which would imply at least the following:
1) There are both long and short forms of the zone markers.
E.g: sub foo($x, $y, ?$z, *a); or
sub foo(pos($x, $y), opt($z), slurp(@a));
(I'm pretty sure this is already planned.)
2) Once the params and their nature have been determined, it should be
possible to use the function with the arguments in the same order
as the declaration:
E.g.: sub bar(pos($a, $b), slurp(@x), named($key));
bar($a, $b, 1,2,3, key => 'jack');
I understand what I'm asking here...the slurpy array must somehow
know to "stop", which is somewhat opposed to the idea of
"slurping". I would be perfectly happy if it were a compile-time
error to declare the slurpy array anywhere other than last, and to
declare positional arguments anywhere other than first.
I guess what I'd really like is to see the concept of 'zones' taken to
its logical extreme; specify the order in which the zones must appear,
and then have a marker that denotes the transition, as opposed to
labelling every parameter. Therefore (violating the rule about the
colon for a moment):
sub foobar(
$x, $y, $z, # required positionals go here
o: $a, $b, $c, # optional positionals go here
n: $d, $e, $f, # named go here
h: %h, # slurpy hash here
s: $s, # slurpy scalar here
a: @a # slurpy array here
);
mygrep( Block &code, a: @list );
init_screen( n: $color, $height, $width, h: %control_values);
etc...
--Dks
