Pre-RCR... nil.empty?

ruby-talk
1

Working with CGI forms and databases, it’s something of a pain having
to do

string = cgi[‘field’][0]

if string.nil? || string.empty?
error "Please specify a value for ‘field’"
end

etc etc…

Would it be silly to have a predefined method:

def nil.empty?
true
end

Cheers

Dave

2

Working with CGI forms and databases, it's something of a pain
having to do

   string = cgi['field'][0]

   if string.nil? || string.empty?
      error "Please specify a value for 'field'"
   end

   etc etc...

Would it be silly to have a predefined method:

   def nil.empty?
      true
   end

Funny you should ask. I've been holding onto said patch for a
while. What you ask/describe is a god-send for web developers, IMHO.
Please let me know if you submit an RCR so I can vote. A patch for
described behavior is attached.

/me chanting: "Go Dave, Go Dave, Go Dave!"

:~) -sc

patch (763 Bytes)

···

--
Sean Chittenden

3

Hi –

Working with CGI forms and databases, it’s something of a pain having
to do

string = cgi[‘field’][0]

if string.nil? || string.empty?
error “Please specify a value for ‘field’”
end

etc etc…

Would it be silly to have a predefined method:

def nil.empty?
true
end

My first thought (slightly devil’s advocate-ish) is that you could do:

if string.to_s.empty? …

Also it feels to me that the idea of a Boolean empty? test for nil
implies that there’s the logical possibility of nil not being empty.
In other words, emptiness might be too rich a characteristic for nil
to have, or something like that.

Just thinking out loud – back at ya –

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

4

string = cgi[‘field’][0].to_s

or

string.to_s.empty?

is good (but not the best) way, I think.

We need something like CGI#get_value_as_string(key)?

In generally (especially in database), NULL and empty string
are not the same. So we should be careful to deal with nil.

Regards,

TAKAHASHI ‘Maki’ Masayoshi E-mail: maki@rubycolor.org
“what is seen is empty, what is empty is seen.”
— HAN NYA SHIN GYO (The Heart of Prajna Paramita Sutra)

···

Dave Thomas Dave@PragmaticProgrammer.com wrote:

Working with CGI forms and databases, it’s something of a pain having
to do

string = cgi[‘field’][0]

if string.nil? || string.empty?
error “Please specify a value for ‘field’”
end

etc etc…

5

i’ve done that too. in fact i’ve added a number of things to the
NilClass:

class NilClass

def
return nil
end

def empty?
true
end

def to_b
false
end

def to_f
0.0
end

alias size to_i
alias length to_i

end

~transami

···

On Sat, 2002-07-06 at 21:09, Dave Thomas wrote:

Working with CGI forms and databases, it’s something of a pain having
to do

string = cgi[‘field’][0]

if string.nil? || string.empty?
error “Please specify a value for ‘field’”
end

etc etc…

Would it be silly to have a predefined method:

def nil.empty?
true
end

Cheers

Dave

–
~transami

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

6

Dave Thomas Dave@PragmaticProgrammer.com wrote in message news:m24rfcb5e7.fsf@zip.local.thomases.com…

Working with CGI forms and databases, it’s something of a pain having
to do

string = cgi[‘field’][0]

if string.nil? || string.empty?
error “Please specify a value for ‘field’”
end

etc etc…

Would it be silly to have a predefined method:

def nil.empty?
true
end

Since there seems to be some opposition to this, how about

def nil.empty_or_nil?
true
end

class Object
def empty_or_nil?
empty?
end
end

But Dave - CGI? I’m disappointed. :wink:

Avi

7

Dave Thomas Dave@PragmaticProgrammer.com wrote in message news:m24rfcb5e7.fsf@zip.local.thomases.com…

Working with CGI forms and databases, it’s something of a pain having
to do

string = cgi[‘field’][0]

if string.nil? || string.empty?
error “Please specify a value for ‘field’”
end

This is related to the way cgi handles multiple parameters. Your
first test, string.nil? is necessary b/c cgi[‘field’] returns an
array, which may be empty.

There was discussion starting from [ruby-talk: 39898]. In [ruby-talk:
39962], Wakou Aoyama made this (excellant) suggestion:

cgi.rb has undocumented method “CGI#param”.

cgi.param[“name”] # == cgi.params[“name”].join(“\0”)

now : cgi[“name”] == cgi.params[“name”]
future?: cgi[“name”] == cgi.param[“name”]

If Wakou changes to this, then I believe string.nil? will be
unnecessary.

~ Patrick

8

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

Also it feels to me that the idea of a Boolean empty? test for nil
implies that there’s the logical possibility of nil not being empty.
In other words, emptiness might be too rich a characteristic for nil
to have, or something like that.

And of course the existing Nil#nil? test is useful for those quantum
computers we’re been hearing about… :slight_smile:

Cheers

Dave

9

TAKAHASHI Masayoshi maki@rubycolor.org writes:

In generally (especially in database), NULL and empty string
are not the same. So we should be careful to deal with nil.

Agreed, but having ‘nil’ respond true to empty? means I can do

fred.empty?

and

fred.nil?

so I don’t lose anything. I seems that having to convert something to
a string to save a test is slightly wasteful… :slight_smile:

Cheers

Dave

10

“David Alan Black” in message
…
…

Would it be silly to have a predefined method:

def nil.empty?
true
end
…
Also it feels to me that the idea of a Boolean empty? test for nil
implies that there’s the logical possibility of nil not being empty.
In other words, emptiness might be too rich a characteristic for nil
to have, or something like that.
…

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)

fitting in well with nil.to_i == 0 and the recent addition nil.to_f ==
0.0.

My feeling that all of those extra nil functionalities waters down nil’s
``nilness’'. In numerical terms the correct interpretation of nil is
sometimes +/- infinity (not to be mistaken with the fake
Float infinities) or even -1. For example, the silly expression

b.max.to_i < a.max.to_i # => true for all Array’s b < a

as long as b != . If the line

         stringy.nil? || stringy.empty?

becomes to repetitive one can always make an harmless
alteration like

class NilClass
def noe?() true end
end

class String
alias :noe? :empty?
end

/Christoph

···

On Sun, 7 Jul 2002, Dave Thomas wrote:

11

Hi –

Dave Thomas Dave@PragmaticProgrammer.com wrote in message news:m24rfcb5e7.fsf@zip.local.thomases.com…

Working with CGI forms and databases, it’s something of a pain having
to do

string = cgi[‘field’][0]

if string.nil? || string.empty?
error “Please specify a value for ‘field’”
end

etc etc…

Would it be silly to have a predefined method:

def nil.empty?
true
end

Since there seems to be some opposition to this, how about

def nil.empty_or_nil?
true
end

class Object
def empty_or_nil?
empty?
end
end

Interesting that this discussion sort of swirls around an old issue –
namely, the fact that in Ruby empty strings are true. (I’m not
adducing this as evidence that they should be false – just observing
that that’s the territory we seem to be on.)

I keep thinking it feels like there’s some way that to_str could play
a role here… but haven’t thought of it yet.

David

···

On Mon, 8 Jul 2002, Avi Bryant wrote:

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

12

But Dave - CGI? I’m disappointed. :wink:

As opposed to what? mod_ruby?

I have a web site at www.jamesbritt.com. It’s built with Ruby. The
hosting service provides various tools, such as Perl, PHP, MySql, at a
decent price, but they don’t have Ruby. I asked them to install Ruby &
mod_ruby, but they were reluctant, and said I could install my own copy of
Ruby and run CGI scripts if I liked. (I had already been doing that, and I
wonder if they knew that.)

My adventures installing Ruby and running CGI scripts in a machine where I
could never be root, nor alter the httpd.conf file, were interesting.
Given the current dearth of Ruby-friendly hosting services, it made me
wonder how best to construct web stuff that were easy to install and
maintain when the user had restricted control over the host server.

What I would like to see are more “Even a parrot can install it” web tools
for blogging, wikis, content management, and so on. I recently tried to
set up a Ruby-based Wiki, but the two I am aware of are, for me, either too
confusing or feature-rich for my needs. I wound up installing the
‘usedmod’ Wiki, written in Perl, because you literally untar the archive,
edit two lines, and it works. Now, it’s about 4K lines of Perl code, with
logic and presentation horribly mashed together, but the ease of
installation and use can’t be beat.

So, for many folks, CGI is the only Ruby option, and more “parrot-friendly,
untar and go” CGI apps would be a Good Thing to promote Ruby.

James

···

Avi

13

I change it in a few days for ruby1.7(ruby unstable).

···

On Tue, Jul 09, 2002 at 06:44:57AM +0900, Patrick May wrote:

now : cgi[“name”] == cgi.params[“name”]
future?: cgi[“name”] == cgi.param[“name”]

If Wakou changes to this, then I believe string.nil? will be
unnecessary.

–
Wakou Aoyama wakou@ruby-lang.org

14

“Christoph” wrote in
…

b.max.to_i < a.max.to_i # => true for all Array’s b < a
ops;-) <= …

15

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

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.

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

Cheers

Dave

16

everyone’s probably already seen this, but just in case:

in reference to Christoph: why the sarcasim? these methods have been
very useful for me, again and again. they make my code clearer and have
saved me time.

~transami

···

On Sun, 2002-07-07 at 03:19, Christoph wrote:

“David Alan Black” in message
…

On Sun, 7 Jul 2002, Dave Thomas wrote:
…

Would it be silly to have a predefined method:

def nil.empty?
true
end
…
Also it feels to me that the idea of a Boolean empty? test for nil
implies that there’s the logical possibility of nil not being empty.
In other words, emptiness might be too rich a characteristic for nil
to have, or something like that.
…

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)

fitting in well with nil.to_i == 0 and the recent addition nil.to_f ==
0.0.

My feeling that all of those extra nil functionalities waters down nil’s
``nilness’'. In numerical terms the correct interpretation of nil is
sometimes +/- infinity (not to be mistaken with the fake
Float infinities) or even -1. For example, the silly expression

b.max.to_i < a.max.to_i # => true for all Array’s b < a

as long as b != . If the line

         stringy.nil? || stringy.empty?

becomes to repetitive one can always make an harmless
alteration like

class NilClass
def noe?() true end
end

class String
alias :noe? :empty?
end

/Christoph

–
~transami

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

17

Uuumm, I think it’s not to save a test. Converting into
a string is to get response objects as String.

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.

Regards,

TAKAHASHI ‘Maki’ Masayoshi

···

Dave Thomas Dave@PragmaticProgrammer.com wrote:

I seems that having to convert something to
a string to save a test is slightly wasteful… :slight_smile:

18

Hi –

My adventures installing Ruby and running CGI scripts in a machine where I
could never be root, nor alter the httpd.conf file, were interesting.
Given the current dearth of Ruby-friendly hosting services, it made me
wonder how best to construct web stuff that were easy to install and
maintain when the user had restricted control over the host server.

Funny you should mention that: it brings us full circle to the very
interesting post [ruby-talk:43752], which pertains to plans for
hosting a Ruby-friendly Web development environment. Davey, the
person who’s interested in providing this service, is looking for
advice and recommendations on what such a hosting service should
provide. (He offers it already for PHP developers.)

The followups to that post got side-tracked into discussion of vim…
The original post is worth another look.

David

···

On Mon, 8 Jul 2002 james@rubyxml.com wrote:

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

19

Couldn’t we tell CGI what we’re expecting - declare that we expect the
environment to contain certain things and have it gripe if they’re not
there. If nothing was declared then we could still do what we do now
if we wanted.

This seems much more intentional than adding behaviour to nil to me…

Mike

···

In article m2vg7s9o1g.fsf@zip.local.thomases.com, Dave Thomas wrote:

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

Also it feels to me that the idea of a Boolean empty? test for nil
implies that there’s the logical possibility of nil not being empty.
In other words, emptiness might be too rich a characteristic for nil
to have, or something like that.

And of course the existing Nil#nil? test is useful for those quantum
computers we’re been hearing about… :slight_smile:

–
mike@stok.co.uk | The “`Stok’ disclaimers” apply.
http://www.stok.co.uk/~mike/ | GPG PGP Key 1024D/059913DA
mike@exegenix.com | Fingerprint 0570 71CD 6790 7C28 3D60
http://www.exegenix.com/ | 75D2 9EC4 C1C0 0599 13DA

20

did i miss something? how will it become unnecessary?

···

On Mon, 2002-07-08 at 23:36, Wakou Aoyama wrote:

On Tue, Jul 09, 2002 at 06:44:57AM +0900, > Patrick May wrote:

now : cgi[“name”] == cgi.params[“name”]
future?: cgi[“name”] == cgi.param[“name”]

If Wakou changes to this, then I believe string.nil? will be
unnecessary.

I change it in a few days for ruby1.7(ruby unstable).

–
Wakou Aoyama wakou@ruby-lang.org

–
~transami

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