Graham Barr wrote:

> On Wed, Sep 20, 2000 at 10:08:09PM -0700, Glenn Linderman wrote:
> > Russ Allbery wrote:
> >
> > > Why on earth would you want to do this in real code?
> >
> > I wouldn't, of course.  This is just a demonstration that I want both
> > semantics available concurrently.
>
> If you are not going to use it, why implement it ?

I would use the feature; not the particular lines and sequence of code above.

> > > I don't believe you actually need both semantics active at the same time;
> >
> > I do.  Need might be a slightly stronger word than necessary, but "want" and
> > "convenience" sure come strongly to mind... the proposals to switch from one
> > set of semantics to another just don't cut it for ease of use.
>
> How can you convince anyoone if you say you would not use it. For any feature
> enhancement to perl, unless there is a strong case for how it makes
> the labguage easier and better it is just not going to happen.

There is certainly lots of room for multiple interpretations of English language
statements.

The purpose of writing the code sequence was to demonstrate that I want both
semantics available concurrently, not to be, in and of itself, a useful code
sequence.  I interpreted Russ' question as one pertaining to the particular code
sequence itself--why would I want to do that code sequence--and I wouldn't.  What
on earth would I do with all those repititious "true"s?  But the code sequence
does illustrate the coexistance of both undef and NULL semantics in the same code
block, which was its intention.  It tried to be somewhat complete about exercising
different aspects of the semantics of both data values, to avoid rebuttals of
partial solutions that are not satisfactory.

Now you are twisting my words to say I meant I wouldn't use the whole concept.  I
wouldn't be spending the time answering all these EMails if I wouldn't use the
whole concept, and I think you know that, so pardon my use of the word "twisting".

Here is a code sequence that is less demonstrative of the complete sets of
semantics for the two concepts, undef, and null, but is more likely to useful in
real code.  It was, indeed, taken from real code, and modified only slightly.  It
uses DBI, which today returns undef in lieu of NULL, but in writing this sample,
I'm assuming that DBI has been ported or wrapped to return the RFC 263 (v1)
concept of NULL for SQL NULL, and that undef semantics are unchanged.

    # $sth is a DBI statement handle when we get here.
    my $i = 0;
    $display->header($sth, \*STDOUT);
    while (my $rowref = $sth->fetchrow_arrayref()) {
     $i++;
     push ( @lastres, [ @$rowref ] );
     if ( $opt{'--expandcr'} )
     { foreach ( @{$lastres[$#lastres]} )
       { s/\r/\n/g;   # note this line
         print;
       }
     }
     $display->row($lastres[$#lastres]);
    }
    $display->trailer($i);

    my $rows = $i;
    print "[$rows row" . ($rows==1 ? "" : "s") . " affected]\n";

The line with the note currently requires an "if defined $_" conditional, because
possible NULL values come back as undef, and warnings result.  The purpose of the
code is to display data retrieve from a statement and, if the --expandcr option is
specified, preprocess that data before displaying it, changing \r to \n so it
displays correctly on Windoze.

This is a small example, with small ramifications and a one phrase workaround...
just an illustration of the kind of problem solved by using NULL semantics.  But
in using DBI, I find I have to scatter distracting "if defined" and "unless
defined" phrases all over the place to avoid warnings.  With RFC 263, processing
of NULL would happen correctly automatically, without the "if defined" phrases.
And yet, I'd still get nice warnings if I attempted to misuse a variable
containing undef (the initialization default value, as in perl right now).

I hope this small illustration demonstrates the differences in semantics that is
desired, and why they are useful.  When doing more serious data manipulation the
ratio and complexity of "if defined" phrases goes up.

--
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

Reply via email to