develooper Front page | perl.perl5.porters | Postings from January 2022

Re: Things you can't do in a signatured sub

Thread Previous | Thread Next
From:
Darren Duncan
Date:
January 31, 2022 22:20
Subject:
Re: Things you can't do in a signatured sub
Message ID:
64888f4a-0f19-850c-7638-063b2fff8ea8@darrenduncan.net
On 2022-01-31 2:04 p.m., Martijn Lievaart wrote:
> On 1/24/22 07:50, Darren Duncan wrote:
> 
>> I still oppose as wrong-headed the concept of using such sentinel default 
>> values to try and detect when no argument is passed.  The only use of such 
>> default values is when you don't care to distinguish between users explicitly 
>> passing that value from them not passing anything.  When you actually want to 
>> distinguish them not passing a value, DON'T use defaults, and instead use "@" 
>> to capture the list and test the list for presence of an element. -- Darren 
>> Duncan
> 
> I understand what you are saying, and agree to a certain extent, but:
> 
> 1) If a value is documented to mean 'no-parameter', and only that, if you 
> explicitly pass that, you get what you deserve. This is different from using 
> the  generic 'unknown' proposal for this, where unknown can very well be used as 
> legitimately as a meaningful parameter value.
<snip>

A problem with this line of reasoning is it prevents the creation of whole 
classes of generic routines/operators, ones that are supposed to be 
type-agnostic, because it is treating certain things as exceptions.

Would you be happy if Perl didn't have the hash "exists" operator and the only 
way to tell if an element was present was to try and fetch it and test the 
result for "undef"?  A lot of people do it, but its a terrible solution.

I agree that slurpy "@" parameters are not ideal, but having sentinel values as 
the only way to know if an argument was passed is worse.

However, there are yet other options.

Dave Mitchell's so-called "query parameters", where each optional parameter is 
expressed with 2 names where one of the names is a boolean saying if the 
parameter was actually given, would appear to be a good solution.

In any event, a lot of this discussion is effectively on best practices.

Practically speaking it would be best for Perl itself for signatures to support 
multiple ways of doing things, supporting non-slurpy with default values plus 
slurpy, and each routine writer can use the style they want based on what they 
actually need.  People can choose to use sentinels, but those who really need to 
know about a lack of an argument without using a sentinel are also able to do so.

-- Darren Duncan

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About