Pre-RCR... nil.empty?

ruby-talk
21

Hi –

“Christoph” chr_news@gmx.net writes:

Yeah, I agree whole heartedly. Following Dave’s logic it makes sense
to define the all time favorites

    nil#each (do nothing - very useful for tree stuff)

or even

    nil#collect (returning the empty Array)

Of course, nil.to_a already returns , so nil#each arguably should
iterate zero times to be consistent with itself, and once you have an
#each, why not include Enumerable…?

To my mind it isn’t a question of what nil is as much as a question of
pragmatics. If I find myself performing the same double-barreled test
using nil and something else, I ask myself if maybe the behavior of
nil could be improved.

But you could also argue that there’s an element of chance or
coincidence here. Going back to your original problem, it’s true that
cgi.params[“param”][0] could be either nil or “”, and that both of
those are unacceptable. But nil and “” crop up, in this context, for
different reasons: nil indicates no param named “param”, while “”
indicates an existent but zero-length value.

Let’s say that you wanted to check for nil (no such param), and also
wanted to reject the string “abc”. All other values (including empty
string) are acceptable. Then you’d have:

if string.nil? or string == “abc” …

which makes sense because the two tests clearly relate to different
problems (missing param vs. unacceptable value). Now, you could argue
that:

if string.nil? or string == “”

is just a special case of that. The fact that the string you don’t
want happens to be the same as nil.to_s is, arguably, just a
coincidence. The two tests are still testing for very different
things, not each testing for half of one thing.

Still sort of devil’s advocate, but I’m warming to my own argument :slight_smile:

David

···

On Sun, 7 Jul 2002, Dave Thomas wrote:

–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav

22

More than once it has happened to me that I was iterating upon an
array many levels of calling apart from where it was generated… or
should have been generated.

The runtime error when I tried to iterate on what I thought was an
array and instead was still `nil’ helped me greatly to fix the
problem. I can’t imagine how I would have debugged it if it silently
non-iterated.

Massimiliano

···

On Sun, Jul 07, 2002 at 10:24:04PM +0900, Dave Thomas wrote:

Of course, nil.to_a already returns , so nil#each arguably should
iterate zero times to be consistent with itself, and once you have an
#each, why not include Enumerable…?

23

Dave Thomas wrote:

It’s a bit like the story of laying out the paths in the newly
constructed campus. The architect said “don’t lay any concrete
paths. Just cover all the area between the buildings with grass.” A
year later, the grass had worn to show where people actually walked,
and that’s where they then poured the paths.

Hm, the way that story finished (perhaps apocryphally?) is that after
the concrete dried people still made their own paths in the grass…

I’m suggesting that is an idiom is common enough we should perhaps
consider setting it in concrete.

Guess I haven’t done enough cgi to feel strongly one way or the other.
Maybe that suggests it’s cgi that should change?

It could define a constant, Empty, or CGI::Entry::Empty or something, to
be an object that responds to string messages as you want nil to. This
might even include methods like #sub, #translate, etc, in addition to
#empty? so you can safely do the following without checking for the nil
case:

string = cgi[‘field’][0]
case string.downcase! # no need to check for nil
when “ruby”
puts “You win!”
when CGI::Entry::Empty
puts “Try typing in the Language field before you press submit.”
else
# can now assume string.is_a? String
puts “I don’t recognize the language #{string.inspect}.”
end

24

And carrying the analogy a bit further, things sometimes
get a bit muddy before they are made concrete.

Hal Fulton

···

----- Original Message -----
From: “Dave Thomas” Dave@PragmaticProgrammer.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Sunday, July 07, 2002 8:24 AM
Subject: Re: Pre-RCR… nil.empty?

It’s a bit like the story of laying out the paths in the newly
constructed campus. The architect said “don’t lay any concrete
paths. Just cover all the area between the buildings with grass.” A
year later, the grass had worn to show where people actually walked,
and that’s where they then poured the paths.

25

David Alan Black wrote:

The followups to that post got side-tracked into discussion of vim…

I thought with “Ruby development environment” he meant an IDE/editor.

The original post is worth another look.

definitely

Tobi

···

–
http://www.pinkjuice.com/

26

TAKAHASHI Masayoshi maki@rubycolor.org wrote in message news:20020708023508V.maki@rubycolor.org…

It’s important that CGI is not the usual case. In CGI,
NULL response and empty string are not different. But,
as I said, we sometimes distinguish between NULL and
empty string.
Therefore, it’s the problem with CGI, not with NilClass.

I agree with this. CGI interaction with forms has some murky
situations:

An unchecked checkbox will result in no parameter being submited.
A multiple select with nothing selected will result in no parameter.
A radio button with nothing selected will result in no parameter.
An empty text field submits an empty string.
An empty textarea submits an empty string.

The standards are screwy, and this leaves room for discussion about
the ‘best’ way to deal with this parameters. One idea off the top of
my head:

cgi.text[‘field’] => use rules for text fields to determine value
cgi.radio[‘field’] => use rules for radio buttons
cgi.checkbox[‘field’] => use rules for checkbox

and so forth. This isn’t the only solution, I’m not even sure if it’s
the one I prefer :-). I like Wakou’s suggestion that cgi[‘field’]
return cgi.params[‘field’].join(“\0”).

Basically, I think Dave’s problem (having to do 2 checks) originates
with the CGI / form standards, and should be solved within (or near)
the CGI module.

~ Patrick

P.S. I don’t want to suggest that cgi.rb is bad. CGI protocol is bad,
making the design of cgi.rb hard.

27

Tom Sawyer transami@transami.net wrote in message news:1026194588.24015.238.camel@silver…

did i miss something? how will it become unnecessary?

currently:

cgi[“field”] == cgi.params[“field”] # <= these return an array
string = cgi[“field”][0] # <= array may be empty,
thus [0] may be nil
and must be tested

future:

cgi[“field”] == cgi.params[“field”].join # <= returns a string
cgi[“field”].empty? # <= true if “field”
is missing or empty.

Most of (my) time with web applications, I don’t care about testing if
a field is missing. I do care about testing to make sure it’s value
is something sensible. Thus, I don’t miss the distinction of whether
a field is missing or empty.

~ Patrick

28

David Alan Black dblack@candle.superlink.net writes:

But you could also argue that there’s an element of chance or
coincidence here. Going back to your original problem, it’s true that
cgi.params[“param”][0] could be either nil or “”, and that both of
those are unacceptable. But nil and “” crop up, in this context, for
different reasons: nil indicates no param named “param”, while “”
indicates an existent but zero-length value.

Of course, in a pure sense you’re right.

But if you ever wrote a decent sized web application in Ruby, you
might change your mind :slight_smile:

Dave

29

is just a special case of that. The fact that the string you don’t
want happens to be the same as nil.to_s is, arguably, just a
coincidence. The two tests are still testing for very different
things, not each testing for half of one thing.

hmmm…that’s a good case. by having empty? defined in nil, the only way
to scheck for an empty string and be sure its an empty string versus nil
is to use == ‘’. empty? wouldn’t work anymore. of course you can still
ask using .nil? so i tend to think that’s okay: usually nil is not
something being delt with directly, but is a side effect of, for
instance, a missing has parameter, etc.

~tranasmi

···

On Sun, 2002-07-07 at 07:41, David Alan Black wrote:

Hi –

On Sun, 7 Jul 2002, Dave Thomas wrote:

“Christoph” chr_news@gmx.net writes:

Yeah, I agree whole heartedly. Following Dave’s logic it makes sense
to define the all time favorites

    nil#each (do nothing - very useful for tree stuff)

or even

    nil#collect (returning the empty Array)

Of course, nil.to_a already returns , so nil#each arguably should
iterate zero times to be consistent with itself, and once you have an
#each, why not include Enumerable…?

To my mind it isn’t a question of what nil is as much as a question of
pragmatics. If I find myself performing the same double-barreled test
using nil and something else, I ask myself if maybe the behavior of
nil could be improved.

But you could also argue that there’s an element of chance or
coincidence here. Going back to your original problem, it’s true that
cgi.params[“param”][0] could be either nil or “”, and that both of
those are unacceptable. But nil and “” crop up, in this context, for
different reasons: nil indicates no param named “param”, while “”
indicates an existent but zero-length value.

Let’s say that you wanted to check for nil (no such param), and also
wanted to reject the string “abc”. All other values (including empty
string) are acceptable. Then you’d have:

if string.nil? or string == “abc” …

which makes sense because the two tests clearly relate to different
problems (missing param vs. unacceptable value). Now, you could argue
that:

if string.nil? or string == “”

is just a special case of that. The fact that the string you don’t
want happens to be the same as nil.to_s is, arguably, just a
coincidence. The two tests are still testing for very different
things, not each testing for half of one thing.

Still sort of devil’s advocate, but I’m warming to my own argument :slight_smile:

David

–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav

–
~transami

“They that can give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety.”
– Benjamin Franklin

30

that’s the future of cgi? begats! isn’t that going to break existing
code? everywhere i put cgi[‘field’], such that i expect the array, will
have to be changed to cgi.params[‘field’]. is that correct? well, i can
live with that. its seems like the better way, but i’ll have work to do!

yet, has anyone thought anymore on “preconditioning” cgi to know what to
expect? could be useful for typecasting, formating, and error catching,
as well as the aforementioned.

~trasnami

···

On Tue, 2002-07-09 at 14:47, Patrick May wrote:

Tom Sawyer transami@transami.net wrote in message news:1026194588.24015.238.camel@silver…

did i miss something? how will it become unnecessary?

currently:

cgi[“field”] == cgi.params[“field”] # <= these return an array
string = cgi[“field”][0] # <= array may be empty,
thus [0] may be nil
and must be tested

future:

cgi[“field”] == cgi.params[“field”].join # <= returns a string
cgi[“field”].empty? # <= true if “field”
is missing or empty.

Most of (my) time with web applications, I don’t care about testing if
a field is missing. I do care about testing to make sure it’s value
is something sensible. Thus, I don’t miss the distinction of whether
a field is missing or empty.

~ Patrick

–
~transami

“They that can give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety.”
– Benjamin Franklin

31

Again, a reason why I think CGI#params should return a Param that
inherits from Array rather than simply return an Array of String
and NilClass objects … :wink:

Then you could happily define Param#empty? to Do The Right Thing for
you.

– Dossy

···

On 2002.07.07, Dave Thomas Dave@PragmaticProgrammer.com wrote:

David Alan Black dblack@candle.superlink.net writes:

But you could also argue that there’s an element of chance or
coincidence here. Going back to your original problem, it’s true that
cgi.params[“param”][0] could be either nil or “”, and that both of
those are unacceptable. But nil and “” crop up, in this context, for
different reasons: nil indicates no param named “param”, while “”
indicates an existent but zero-length value.

Of course, in a pure sense you’re right.

But if you ever wrote a decent sized web application in Ruby, you
might change your mind :slight_smile:

–
Dossy Shiobara mail: dossy@panoptic.com
Panoptic Computer Network web: http://www.panoptic.com/
“He realized the fastest way to change is to laugh at your own
folly – then you can let go and quickly move on.” (p. 70)

32

Hello,

that’s the future of cgi? begats! isn’t that going to break existing
code? everywhere i put cgi[‘field’], such that i expect the array, will
have to be changed to cgi.params[‘field’]. is that correct? well, i can
live with that. its seems like the better way, but i’ll have work to do!

$ ruby -r./cgi.rb -e’value = CGI.new[“key”]; p value’ key=value
“value”
$ ruby -r./cgi.rb -e’value, = CGI.new[“key”]; p value’ key=value
“value”

cgi[‘field’] is return String. but,

$ ruby -r./cgi.rb -e’value = CGI.new[“key”][0]; p value’ key=value
WARNING! cgi[‘key’] is return String. if want Array, use cgi[‘key’].params
“value”

$ ruby -r./cgi.rb -e’value = CGI.new[“key”].first; p value’ key=value
WARNING! cgi[‘key’] is return String. if want Array, use cgi[‘key’].params
“value”

How about this?

Of course, in the future, cgi[‘field’] is return pure String, and,
warning is disappear.

···

On Wed, Jul 10, 2002 at 06:02:45AM +0900, Tom Sawyer wrote:

–
Wakou Aoyama wakou@ruby-lang.org

33

Oh, mistake!

···

On Wed, Jul 17, 2002 at 03:33:43AM +0900, Wakou Aoyama wrote:

WARNING! cgi[‘key’] is return String. if want Array, use cgi[‘key’].params

WARNING! cgi[‘key’] is return String. if want Array, use cgi.params[‘key’]

–
Wakou Aoyama wakou@ruby-lang.org

34

very helpful. thanks. should make quick work of it.

···

On Tue, 2002-07-16 at 12:33, Wakou Aoyama wrote:

$ ruby -r./cgi.rb -e’value = CGI.new[“key”][0]; p value’ key=value
WARNING! cgi[‘key’] is return String. if want Array, use cgi[‘key’].params
“value”

$ ruby -r./cgi.rb -e’value = CGI.new[“key”].first; p value’ key=value
WARNING! cgi[‘key’] is return String. if want Array, use cgi[‘key’].params
“value”

How about this?

Of course, in the future, cgi[‘field’] is return pure String, and,
warning is disappear.

–
~transami

(") dobee dobee do…
\v/
^ ^