On Fri, 19 Jan 2024 at 08:09, Veesh Goldman <rabbiveesh@gmail.com> wrote:
> I highly prefer Paul's suggestion for a few reasons
>
> 1. If you always allow any param to be called by name, you've created a
> huge maintenance burden on the library - now everything is a contract
> (unless there's magic syntax for private non-nameable Params, which doesn't
> sound good)
>
My opinion says otherwise, having this syntax will simplify maintenance.
Of course, if you decide to rename parameter ... but that's different story.
I'd suggest you to take a look at C# / Kotlin behaviour of named arguments
- parameters are always positional
- user can choose named argument syntax for better readability
Usage of sigil in binding simplifies reading as well as (with proposed
syntax) allows passing multiple list arguments.
For example, allows do distinguish expected cardinality by declaration and
not by guessing, or smarter wantarray-like behaviour.
sub foo (optional $id, optional @id@).
my $scalar = foo (:= $id => [ 1 ]);
my @list = foo (:= @id => ( [ 1 ], [ 2 ] ));
If you want to discuss let's do it in separate thread with examples
From user's point of view, it's up to caller to decide what is important
(if anything) and what is not so much.
In business logic you often have functions with multiple possible keys or
all optional.
Also there are also different possibilities to extends signatures using
similar syntax (I already posted it some time ago), for example:
- mutually exclusive parameters:
sub connect (
$username := required => ! $token := requires => ! $token,
$password := optional := requires => ! $token && $login,
$token := required => ! $login := requires => ! $login,
)
required / requires takes expression using other parameter names and
evaluates them as as "is provided" / "is not provided"
> 2. This syntax can easily double for hash destructuring and callsite
> shorthand and make sense logically too, whereas the callsite only syntax
> would not
>
> On Fri, Jan 19, 2024, 07:26 Branislav Zahradník <happy.barney@gmail.com>
> wrote:
>
>>
>>
>> On Thu, 18 Jan 2024 at 23:50, Paul "LeoNerd" Evans <
>> leonerd@leonerd.org.uk> wrote:
>>
>>> Something I've written about a few times in various "what might come
>>> next in Perl" talks, has been adding some kind of named parameter
>>> support to subroutine signatures.
>>>
>>> I now have an implementation as part of XS::Parse::Sublike, that I've
>>> been using in a few places and seems to be fine:
>>>
>>> https://metacpan.org/pod/Sublike::Extended#Named-parameters
>>>
>>> How would folks feel about me writing this up into a real PPC document,
>>> ideally with the aim of trying to get something in place in time for
>>> 5.40?
>>>
>>>
>> Seems to me this is raku style extensions suppressing context of user
>> (from code base maintenance point of view - bad idea)
>>
>> How named arguments are implemented in other languages:
>>
>> https://github.com/happy-barney/perl-wish-list/blob/master/named-arguments/spec/named-arguments-in-other-languages.md
>>
>> WIP on changes to calling syntax allowing mixing positional and named
>> arguments as well as multiple list arguments
>>
>> https://github.com/happy-barney/perl-wish-list/blob/master/named-arguments/spec/named-arguments.md
>>
>> Shortly:
>> - there will be no difference in signature declaration
>> - there will be change in calling syntax and binding
>>
>> Example (extreme):
>> sub foo ($a, $b, @a, @b) ..
>>
>> @b = (10..20);
>> foo (
>> := $b => 1
>> 2,
>> := @b
>> 3, 4, 5
>> );
>>
>> effective binding:
>> - $a == 2
>> - $b == 1
>> - @b == (10..20)
>> - @a == 3,4,5
>>
>> plus bonus:
>> it will be nice to have %_ to access arguments by name (eg to
>> differentiate when optional argument was not provided and when provided
>> with 'undef' value)
>> - $_{'$a'} == 2
>> - $_{'@a'} == \ @a (as populated)
>>
>>
>>
>>
>>> --
>>> Paul "LeoNerd" Evans
>>>
>>> leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
>>> http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
>>>
>>