On Sat, 18 Dec 2021 11:09:02 +0000 (UTC), Ovid via perl5-porters <perl5-porters@perl.org> wrote: > 2VL logic on undef/null values been broken for a long time and forces > developers to remember to always write special case code to handle > this. > > However, while we could correct the underlying issue, going further > into 4VL or 5VL adds complications that I doubt most developers are > going to understand. In other words, SIMPLICITY IS YOUR FRIEND. > > We don't need "perfect" because making something that covers all > possible cases is simply going to be a mess and might even be > counter-productive. For example, if you're unauthorized to get a > value but you see that it's a "known defined value", that's an > information leak. Also, given Merijn's original list: > > 1. Known defined value > 2. Known undefined value > 3. Unknown value > 4. Unauthorized to get the value > 5. Value is defined but unauthorized to get it > > I don't see how 4+1 is different from 5. So we can bikeshed this to > death, or fix the major underlying problem: $salary += 1000. > Congrats. You've just given a raise to an unpaid volunteer. I've met one case where the design was authorized to give me back the fact that the value is known but that I was not not authorized to get the value by this interface. I needed higher authorization to get the actual value. The more-value in this is that one can decide to pursue getting the value if required for a job which can be omitted if the feedback is that the value is unknown anyway. Edge cases, but useful. In my example 1 implied also getting the actual value > Ovid -- H.Merijn Brand https://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.33 porting perl5 on HP-UX, AIX, and Linux https://tux.nl/email.html http://qa.perl.org https://www.test-smoke.orgThread Previous | Thread Next