Russ Allbery wrote:
> Glenn Linderman <[EMAIL PROTECTED]> writes:
>
> > In my opinion, which you probably will also not agree with, attempting
> > to toggle between the current undef semantics and tristate semantics is
> > like trying to stuff three values into one bit.
>
> I do understand the argument. I just see confusion either way, and I
> think that approach would be the least confusing and allow the code to
> remain the most Perl-like. I can see arguments the other way; that's just
> my opinion.
>
> > The problem is, when you toggle the pragma, all variables whose value is
> > undef suddenly have the tristate semantics, and when you toggle it back,
> > all the variables whose value is undef suddenly have the undef
> > semantics. This leaves it purely to the programmer to make sure that
> > the pragma is used in exactly the right places, and, when tristate
> > semantics are in effect makes unavailable the normal, helpful warnings
> > that Perl produces when you attempt to misuse undef values.
>
> 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.
> To me, toggling the semantics of the variables which are already undef
> strikes me as just what I'd want.
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.
> > I guess that since you have no intention of using the tristate
> > semantics, you don't care whether it is easy to code using them.
>
> Comments like this are what is making it very difficult for me to continue
> discussing this with you.
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.
> You don't actually know what type of Perl I
> write or whether or not I'd use the semantics or not. As a matter of
> fact, I find them very interesting and fully do expect to use those
> semantics if they're implemented in Perl, particularly given that I'm
> likely to be doing a lot more database and SQL coding in the future than I
> am currently.
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? Since you don't need the current set of semantics? I'm
sure there must be some logic behind your opinion, and I'd like to understand
it, which I currently do not. 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.
To me, having a separate null and undef makes the explanations of both
concepts simpler, because they are independent.
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. In
fact, I haven't yet figured out how the pragma approach can possibly support
multiple NULL values at all. Now I grant you that this is a theoretical
issue, since none of today's databases support multiple types of NULL AFAIK.
However if, to support multiple NULL values in the future, the whole basis of
the support had to change from a tristate pragma to a set of "special
non-values", that would appear to cause more confusion in the future. On the
other hand, perhaps multiple NULL values will continue to get "defered to a
future SQL standard" as they have for some years now.
--
Glenn
=====
Even if you're on the right track,
you'll get run over if you just sit there.
-- Will Rogers
_______________________________________________
Why pay for something you could get for free?
NetZero provides FREE Internet Access and Email
http://www.netzero.net/download/index.html
