Front page | perl.perl5.porters |
Postings from October 2022
On Sat, Oct 08, 2022 at 07:13:17PM +0200, Branislav Zahradník wrote:
> Please differentiate between named argument function call syntax and named
> parameter extended signatures.
I think I covered that in my email from an hour ago.
> What we should answer first is want we want:
> - do we want to limit arguments to $ sigil (+ slurpy) ?
Arguments are an arbitrary list passed to a function. It is up to the
coder of that function how they precess those arguments, assign values to
local variables, check for errors etc. They may use the traditional
approach of directly accessing @_, or use the new signature feature
to allow the perl internals to more efficiently do some of that processing
in an automated fashion.
> - do we want freedom of function user to choose how to call function? (for
> examples functions in
> Postgresql, C#, Kotlin, Python)
I have no idea what any of those languages do. But in general, the perl
philosophy is that a user can construct the arguments to a function however
they chose:
foo(1,2,3,4);
@a = (2,3); foo (1, @a,4);
foo((1,$cond ? (2,3) : (-2,-3)), 4);
etc.
And this would be unaffected by function's signature, which isn't examined
by perl at the call site at compile-time, nor run-time. If you want
something like that, then that's what prototypes are for.
> - do we want extended constraints? (eg: $login and $oauth are mutually
> exclusive, $password must be specified when $login exists)
I've never considered constraints that affect more than a single
parameter. I have no strong opinion on whether they would be a good idea
or not. I would likely want to see some proposed syntax/semantics before
forming an opinion,
--
The crew of the Enterprise encounter an alien life form which is
surprisingly neither humanoid nor made from pure energy.
-- Things That Never Happen in "Star Trek" #22
Thread Previous
|
Thread Next