Front page | perl.perl5.porters |
Postings from January 2022
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. 2) You can always do this in your project, if there is no generic 'no-parameter' value. It's your project/library, you are free to define such a value and use it. In fact, I think this is what we can suggest right now as a good technique to solve this problem. Again, if someone maliciously passes such a value explicitly, they get what they deserve. I think this is greatly preferable to telling people to use a slurpy parameter. You just reintroduced @_, as far as my programmer experience is concerned. I really, really hate that. (Note that I hate the use of ref_addr too, but that can probably be hidden somewhat.) Bottom line, I think, if we want to depricate @_ in signatured subs -- which we probably want, as this is the only realistic opportunity to do so -- there are two techniques (no-parameter and slurpy last param) which make determining arity possible, while we can think of an even better way later (soonish!). HTH, M4Thread Previous | Thread Next