develooper Front page | perl.perl5.porters | Postings from December 2021

Re: Pre-RFC: `unknown` versus `undef`

Thread Previous | Thread Next
H.Merijn Brand
December 18, 2021 16:56
Re: Pre-RFC: `unknown` versus `undef`
Message ID:
On Sat, 18 Dec 2021 11:09:02 +0000 (UTC), Ovid via perl5-porters <> 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   Perl Monger
using perl5.00307 .. 5.33        porting perl5 on HP-UX, AIX, and Linux

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About