Front page | perl.perl5.porters |
Postings from December 2021
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.org
Thread Previous
|
Thread Next