|
Posted by Peter J. Holzer on April 29, 2008, 3:12 pm
Please log in for more thread options
>
> >> The term "null string" for what would more reasonably called an
> >> "empty string" is a mistake. When the Camel is wrong, it
^^^^^^^^^^^^^^^^^^^^^^^
> >> should be corrected, not defended as if it were Holy Writ.
>
> PJH> It isn't wrong.
>
> I didn't say it was *wrong*;
I have underlined it above to refresh your memory.
> I said it was a mistake, because of the very ambiguity that you are
> alternately defending and insisting is not present.
>
> PJH> It may be that Ted and you are unfamiliar with this
> PJH> term. That doesn't make it wrong (If every English term I'm
> PJH> unfamilar with was wrong, the English would have a poor
> PJH> language, indeed). It may in some context be ambiguous. I was
> PJH> going to criticize Ben (was it Ben?) for using the phrase in
> PJH> this thread, but then I noticed that he hadn't brought it up,
> PJH> but was merely discussing a quote from the Camel book.
>
> In other words, if Ben had written it originally, you would have
> considered it a fault, but because it can be found in the Camel, it
> becomes Holy Writ and thus to be defended as an article of faith.
No. If Ben had written it I would have considered it a fault because he
used the term in a discussion which involved the term "NULL" as defined
in SQL. Using the term "null string" in such a discussion should be
avoided just because it sounds too similar. But Wall et al were not
discussing SQL NULL values in their book, and probably not even C null
pointers (I don't have the book at hand, so I can't check). So they had
no reason to avoid this common term.
> PJH> And I don't think you can fault Wall et al for not
> PJH> anticipating that someone with a Java and SQL background
> PJH> might misunderstand an term with an otherwise quite specific
> PJH> meaning.
>
> Hardly; as I pointed out, it's also unclear in meaning for those of us
> with C backgrounds as well,
I am one of "those of us with C backgrounds". I've been programming in C
for more than 20 years now (although I've switched mostly to Perl since
the mid-1990s).
> especially when the term "empty string" conveys the same information
> without the prospect of ambiguity.
I wouldn't bet that nobody can misunderstand "empty string", either. The
English language (like any natural language) is intrinsically ambiguous
and context-sensitive. Yes, the meaning of "empty string" or
"zero-length string" is probably easier to guess for someone who doesn't
know the term, but my point is that Wall et al had no reason to think
that a reader might not know the term. Ted complained that they didn't
define it. The book also uses the word "dog" without defining it (and in
four different meanings in the same sentence, no less!), because they
assume that the reader knows the meaning(s) of the word. Now, natural
language changes, and jargon changes even faster. It might be that a
term which had only one meaning in 1990 (when the first edition of the
book was written), is now ambiguous. Then it should be changed. But I
don't see the fact that one person in 18 years misinterpreted that
sentence as proof that this is the case.
> This has not appeared to be a rational argument for some time, and if
> you prefer to defend inaccuracy and ambiguity
On the contrary, I always try to be as precise as possible. I would
never call a null pointer a null string, because a pointer and string
just aren't the same. I also try not gratuitously use terms which
already have a precise meaning in some other meaning. So, because "null
string" already has the meaning "zero-length string", I wouldn't call a
varchar (SQL) or String (Java) variable with the value null a "null
string". That's just confusing.
> with the delusion that it's instantly clear to everyone except Java
> programmers, by all means, carry on.
In more than 20 years of programming (and reading technical literature
in English) I've come across the term "null string" numerous times. I
cannot recall a single instance where it wasn't unambiguosly synonymous
with "empty string". Only when googling for the term I found a few
scattered Java tutorials which used it differently.
hp
|
|
Posted by Martijn Lievaart on April 24, 2008, 6:31 pm
Please log in for more thread options
On Thu, 24 Apr 2008 14:10:08 +0000, Ben Bullock wrote:
>
>>> Try running the following script to clarify what this means:
>>>
>>> #!/usr/bin/perl
>>> use warnings;
>>> use strict;
>>> my $a;
>>> my $b = "";
>>> print "a is defined\n" if defined($a); print "b is defined\n" if
>>> defined($b);
>>>
>>> Here $b is a "real null string" and $a is undefined.
>
> Excuse me, this should say '$b is a "defined null string"' not "real".
No, $b is an empty string. Certainly not a null string. There is no such
thing as a null string in perl. C++ has a null string concept IIRC, but
Java and C don't, they allow the variable to be set to NULL, which in
perl is setting it to undef.
M4
|
|
Posted by Ben Bullock on April 24, 2008, 8:27 pm
Please log in for more thread options > On Thu, 24 Apr 2008 14:10:08 +0000, Ben Bullock wrote:
>> Excuse me, this should say '$b is a "defined null string"' not "real".
>
> No, $b is an empty string. Certainly not a null string. There is no such
> thing as a null string in perl. C++ has a null string concept IIRC, but
> Java and C don't, they allow the variable to be set to NULL, which in
> perl is setting it to undef.
You're taking this phrase out of context. If you go back and read the
previous messages in the thread, you'll see why I used the terminology
"defined null string".
|
|
Posted by Ted on April 24, 2008, 10:01 pm
Please log in for more thread options On Apr 24, 8:27=A0pm, benkasminbull...@gmail.com (Ben Bullock) wrote:
> > On Thu, 24 Apr 2008 14:10:08 +0000, Ben Bullock wrote:
> >> Excuse me, this should say '$b is a "defined null string"' not "real".
>
> > No, $b is an empty string. Certainly not a null string. There is no such=
> > thing as a null string in perl. C++ has a null string concept IIRC, but
> > Java and C don't, they allow the variable to be set to NULL, which in
> > perl is setting it to undef.
>
> You're taking this phrase out of context. If you go back and read the
> previous messages in the thread, you'll see why I used the terminology
> "defined null string".
Look Ben, there is no need for a big dispute here. The fact is that
Wall et al. do not define their phrase "defined null string". They
might mean an empty string, they might not. But there is no way to
tell from that book. If you know of another book where they, or
someone else for that matter, give that definition, great. Quote it
and cite it (but give the full citation so I can get an inter-library
loan in order to be able to read it). If there is, in perl, such a
definition, point me to the correct page in the perl docs so I can
read up on it. At present, I have no basis for adequately assessing
what Wall et al. meant by that phrase, because they didn't specify
that in that book. Nor do I see any grounds here to assess whether
your use of such terminology is your own invention or something you
got from some other authority. If it is your own invention, that is
fine and you should say so, but if so you'd be wrong to be upset with
me for not accepting it. If it is something you got from some
authority, then say so and provide me with the references I can use to
find out why that authority introduced such an idea. If Martijn is
right in saying there is no such thing as a defined null string in
perl, then I'd have to infer that Wall et al made a poor choice of
words in their text where they described undefined, and again there is
left no basis for judging whether your use of the phrase is correct,
or if I would be better off to take Martijn's word.
Please, just quote and cite your sources for the idea that the empty
string ought to be equated with a 'defined null string'. I am here
only to learn about perl, and this idea you're expressing is so alien
that I want to know where it comes from and why anyone would think
that it makes sense in some context, or any context, to conflate the
two ideas. Merely repeating your claim that they're the same thing,
and my rejection of such a conflation of distinct ideas, gets us
nowhere.
Cheers,
Ted
|
|
Posted by Ted on April 24, 2008, 9:15 pm
Please log in for more thread options > On Thu, 24 Apr 2008 14:10:08 +0000, Ben Bullock wrote:
>
> >>> Try running the following script to clarify what this means:
>
> >>> #!/usr/bin/perl
> >>> use warnings;
> >>> use strict;
> >>> my $a;
> >>> my $b =3D "";
> >>> print "a is defined\n" if defined($a); print "b is defined\n" if
> >>> defined($b);
>
> >>> Here $b is a "real null string" and $a is undefined.
>
> > Excuse me, this should say '$b is a "defined null string"' not "real".
>
> No, $b is an empty string. Certainly not a null string. There is no such
> thing as a null string in perl. C++ has a null string concept IIRC, but
> Java and C don't, they allow the variable to be set to NULL, which in
> perl is setting it to undef.
>
FTR, C++ does not have a null string, at least not in the definition
of the language or in the standard C++ library. Like C it uses it to
mark the end of a string, although standard practice is to eschew the
use of C style string arrays, using std::string instead. Compare the
use of the data and c_str member functions of std:;string, if you're
interested. And of course, like C, C++ has the idea of a null
pointer, and this is represented by 0.
If you know of a reference that talks about a null string concept for C
++, I'd love to hear about it (off list, since that probably takes us
too far afield for this forum).
Of course, there is nothing to stop you from representing the idea of
a null string by deriving a new class from std::string, adding a
boolean data member to represent whether or not the instance is
supposed to be null and over-riding any member functions for which you
require specific behaviours of your null string. And of course, you
can do much the same thing in any object oriented language, including
Perl.
Cheers,
Ted
|
| Similar Threads | Posted | | Multiple Inheritance: mixed base class refs (hash, array) | April 29, 2005, 2:29 am |
| FAQ 9.3: How can I get better error messages from a CGI program? | December 5, 2004, 6:03 pm |
| FAQ 9.3: How can I get better error messages from a CGI program? | December 29, 2004, 12:03 pm |
| FAQ 9.3 How can I get better error messages from a CGI program? | March 25, 2005, 12:03 pm |
| FAQ 9.3 How can I get better error messages from a CGI program? | June 4, 2005, 5:03 am |
| FAQ 9.3 How can I get better error messages from a CGI program? | September 23, 2005, 4:03 pm |
| FAQ 9.3 How can I get better error messages from a CGI program? | November 29, 2005, 5:03 am |
| FAQ 9.3 How can I get better error messages from a CGI program? | September 17, 2006, 9:03 pm |
| FAQ 9.3 How can I get better error messages from a CGI program? | March 21, 2007, 3:03 am |
| FAQ 9.3 How can I get better error messages from a CGI program? | November 11, 2007, 9:03 pm |
|
XML Sitemap