Front page | perl.perl5.porters |
Postings from January 2022
On 2022-01-19 4:41 a.m., Dave Mitchell wrote:
> 1) Another advantage of not populating @_ is that it removes a whole bunch
> of edge cases concerning what happens if @_ is modified during arg
> processing. In particular things become more complicated if we ever
> implement named args: this is where the caller does foo(y =>2, x =>1) to
> call sub foo(:$x, :$y) {} - here the processing of default args etc
> doesn't follow a simple L-R ordering and it's more likely that @_ could
> get modified mid-processing.
I know this isn't the main point of what you're saying, but I want to address
the matter of named arguments.
Your example code using "=>" may have just been representative and not literal.
But I want to argue that when/if Perl does add native support for named
parameters/arguments, which I hope it does, I feel that we must use a NEW syntax
to indicate it, and NOT use "=>".
While Perl devs are used to "=>" to indicate fake named parameters/arguments,
the fact remains that this is really just a "fat comma" and a lot of code is
going to break if Perl starts saying that the syntax now maps to named parameters.
I propose following an example which is very common in other languages and data
formats, and is also better Huffman coded, which is to use the colon ":" to
indicate named parameters or arguments.
This shouldn't conflict with any other use of the colon that I'm aware of.
So these two things should continue to have the same meaning, and map to 2
positional parameters:
foo('x', 'y')
foo(x => 'y')
... and this would continue to map to a single positional parameter which is a
hashref:
foo({x => 'y'})
Whereas this would map to a named parameter:
foo(x: 'y')
-- Darren Duncan
Thread Previous
|
Thread Next