Front page | perl.perl5.porters |
Postings from August 2023
Tiny Signatures Extension Discussion
Thread Next
From:
Ovid
Date:
August 19, 2023 14:56
Subject:
Tiny Signatures Extension Discussion
Message ID:
CA+M4CHu2qK2hdxhbh-8usgbisNea1T5LvQqC0Oc3vZz20aS-Ng@mail.gmail.com
Back in 2019, Dave Mitchell shared the Jumbo Signatures extension discussion
<https://www.nntp.perl.org/group/perl.perl5.porters/2019/11/msg256677.html>.
That thread was amazing. Lots of great ideas.
*Lots* of great ideas means lots of work and makes it harder to get it
accepted. I want to start smaller. Stealing Borrowing some of his ideas,
but simplifying some of them (while allowing room for expansion), and
focusing on "high demand" features. Further, by starting smaller, we have
fewer bugs.
The features I want to focus on are:
1. Attributes for signatures variables
2. Named arguments
3. Aliasing
This is a small list, but focusing on those things that, er, I most want.
By having a smaller discussion, we have a better chance of moving forward,
and if we can get to an accepted PPC, we can give a strong signal to the
Perl community that we're moving forward.
<https://gist.github.com/#signature-attributes>Signature Attributes
This is on hold while Paul continues to work on feature-class
<https://www.nntp.perl.org/group/perl.perl5.porters/2023/08/msg266785.html>
<https://gist.github.com/#named-arguments>Named Arguments
For a first pass, named arguments and positional arguments would be
mutually exclusive. This is a limitation that can be lifted in future
versions, if needed. This has the advantage that (as far as I can tell),
it's forward-compatible with Dave's proposal.
sub orders(:$name, :$since //= undef, :@items) { ... }
The above would be sort of equivalent to:
sub orders {
my %arg_for = @_;
my $name = delete $arg_for{name} or die ...;
my $since = delete $arg_for{since};
my @items = exists $arg_for{items} && 'ARRAY' eq ref $arg_for{items}
? delete $arg_for{items}->@*
: die ...;
if ( keys %arg_for ) {
die ...; # unknown keys
}
...
}
Which would you rather write?
It would be called with a flat list:
my $orders = orders( name => $name, since => $date, items => \@items
);# ormy $orders = orders( name => $name, items => \@items );
If we have :$names, of course $arg_for{names} could be an array ref. :@names is
a useful convenience.
<https://gist.github.com/#aliasing>Aliasing
This would depend on attributes in signatures.
sub foo( $bar :alias ) { ... }
In the above, regardless of what $bar is, it's an alias to the argument
passed to foo, just as if we used $_[0] instead.
This one could *almost* be left off the list, since references are kinda
already aliases. However, when I'm walking and mutating complex data
structures, I don't want to handle the special case of non-reference versus
reference. I just want to know that I can mutate the calling value directly.
Generally speaking, this is a terrible idea. Practically speaking, it makes
some code much simpler and can be extremely performant.
<https://gist.github.com/#ppc>PPC?
Given that this is a much smaller set of suggestions, can we commit to
this? This isn't saying we do this now; it would be saying "we plan to do
this." Named arguments and aliases would go a long way towards killing off
@_ (not really removing it, but making it less much less likely to be
needed).
Not allowing positional and named arguments to be mixed might be
controversial, but I've found that having something like an "options" or "
extra" key works around that nicely.
This would be, like Corinna, an MMVP (a minimally minimal viable product),
with an eye towards later revisiting Dave's jumbo list. However, it would
send a strong signal to the Perl community that popular needs are being
addressed and Perl is maturing into a modern language.
Best,
Ovid
--
Curtis "Ovid" Poe
--
CTO, All Around the World
World-class software development and consulting
https://allaroundtheworld.fr/
Thread Next
-
Tiny Signatures Extension Discussion
by Ovid