Front page | perl.perl5.porters |
Postings from February 2022
On 1/31/22 23:19, Darren Duncan wrote: > On 2022-01-31 2:04 p.m., Martijn Lievaart wrote: >> 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. You are creating a problem that does not exist, I think. Your argument would hold water if I advocated to use unknown or undef or any other value that can legitimately be passed as a parameter for this, which I don't. If it doesn't make sense to pass no-parameter to a function, do not do so. Its presence has no other use than signaling there is no parameter, so it should never be used as a legitimate value. Doctor, it hurts when I press here. Because it should never be passed, and only is meaningful as a default, it can only be passed to a function as a result of a bug by the writer of the signatured sub that uses it. And bugs are bugs, not features. > 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. Undef is a legitimate parameter value, that can be legitimately passed. So this is a non-sequitor. [...] > 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. Agree, that was my conclusion too. So in the end it doesn't matter too much, although I would say both should be in the documentation. M4Thread Previous | Thread Next