Glenn Linderman <[EMAIL PROTECTED]> writes:
> Russ Allbery wrote:
>> Perhaps I don't use those warnings in the same way that you do. I
>> *very* rarely have undefined value warnings in my programs, and when I
>> do they're usually not actually bugs, just things that require a
>> different way of writing to be -w clean. So I don't have as high of an
>> opinion of this warning as being particularly important to debugging; I
>> only find it useful in certainly particular circumstances.
> I can't say that I often get the warning, but when I do, I find it
> generally results from a bug. So something about the way we write code
> is different, I guess.
Most likely. It caught stuff for me before use strict (generally variable
typos) but with use strict, those warnings tend to be either checking for
keys in aggregate structures when they've not been initialized (which is
mostly just an annoyance) or they're just a symptom of something going
wrong somewhere else entirely and aren't particularly helpful in tracking
down where it's going wrong.
> I find this absolutely amazing. You've now convinced me you understand
> the arguments I've been making, and the issues I'm concerned
> about... and yet you still hold this opinion. Certainly we have a
> difference of opinion here.
It's quite possible that I'd have a different opinion if I used it for a
while; I don't know. I think it's worth trying it with undef first and
writing some code that way and seeing how it works and how hard it is to
debug.
> Russ, I apologize. I confused you with someone else in this posting. I
> looked back over your postings, and you, unlike those that seem to just
> hate SQL, have repeatedly expressed interest in using the tristate
> semantics. I've been trying to keep my nose clean regarding remarks
> like this, but I guess my frustration level finally got the better of
> me...and perhaps partly, I guess I stayed up too late last night and
> probably shouldn't be posting this late tonight either.
No problem; it's easy enough to do. :)
> Maybe the enlightenment is shed by your earlier remark: you don't find
> the undef warnings to be particularly important to debugging. So maybe
> that is the reason that you don't see the need to concurrently have both
> sets of semantics available?
That's quite possible.
> Since you don't need the current set of semantics?
The main thing I use undef for is in areas where I'm checking with
defined, which I would assume would continue to work regardless of the
selected semantics of undef. Having undef propagate would make it useful
in additional areas (or at least I think it would). From writing language
parsers, I found that it's useful in areas other than SQL to have a
distinguished value that propagates through any arithmetic operation.
> Going back to your first remark about seeing confusion either way, maybe
> explaining the types of confusion that you see with a separate null and
> undef vs the types of confusion that you see with a tristate pragma
> would help me to grasp that logic.
The main thing I'm worried about with undef plus null is that undef is
already very hard to explain and having an additional parallel concept
that behaves slightly differently and that can easily be confused with
undef is worrisome. The advantage of explaining a tristate pragma is that
with normal undef semantics, most times undef shows up in an arithmetic or
logical operation other than a simple test of true or false, it's
symptomatic of poorly-constructed code; increments are about the only
exception. So the area that tristate logic changes is not something that
we recommend that people use under normal circumstances.
> And if/when my database needs require the use of multiple different NULL
> values (currently they are not there, multiple NULL values do get talked
> about by relational theorists, and there is some move to put them into
> the SQL standard, but it appears they haven't yet appeared in one) I see
> having multiple "special non-values" (as someone else called them) much
> simpler to extend to the concept of multiple NULL values than the pragma
> approach.
Hm. Yes, that's a good point. (At that point, something more like
Quantum::Superpositions may be more what you want.)
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
