NEWBIE QUESTION: pattern with nil
basi
I'm a bit tired typing:
if a == "" or a == nil
if a != "" and a !== nil
I'm sure there is a Ruby way to do this.
Thanks for the help.
basi
Ara.T.Howard
i generally use
harp:~ > cat a.rb
a = 'foobar'
p 42 unless a.nil? or a.empty?
a = nil
p 42 unless a.nil? or a.empty?
harp:~ > ruby a.rb
42
because the meaning is very clear. for shorter i use
harp:~ > cat a.rb
a = 'foobar'
p 42 unless a.to_s.empty?
a = nil
p 42 unless a.to_s.empty?
harp:~ > ruby a.rb
42
cheers.
-a
--
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| Your life dwells amoung the causes of death
| Like a lamp standing in a strong breeze. --Nagarjuna
===============================================================================
David A. Black
On Wed, 10 Aug 2005, basi wrote:
> Hello,
> I'm a bit tired typing:
>
> if a == "" or a == nil
> if a != "" and a !== nil
>
> I'm sure there is a Ruby way to do this.
You can normalize it to a string:
if a.to_s.empty?
or, for the opposite:
unless a.to_s.empty?
David
--
David A. Black
dbl...@wobblini.net
Ara.T.Howard
> Hi --
>
> On Wed, 10 Aug 2005, basi wrote:
>
>> Hello,
>> I'm a bit tired typing:
>>
>> if a == "" or a == nil
>> if a != "" and a !== nil
>>
>> I'm sure there is a Ruby way to do this.
>
> You can normalize it to a string:
>
> if a.to_s.empty?
>
> or, for the opposite:
>
> unless a.to_s.empty?
'normalize' is such a nicer word than 'cast' - i'll take it!
John Carter
> Hello,
> I'm a bit tired typing:
>
> if a == "" or a == nil
> if a != "" and a !== nil
>
> I'm sure there is a Ruby way to do this.
class NilClass
def empty?
true
end
end
if a.empty?
John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john....@tait.co.nz
New Zealand
Carter's Clarification of Murphy's Law.
"Things only ever go right so that they may go more spectacularly wrong later."
From this principle, all of life and physics may be deduced.
BearItAll
> On Wed, 10 Aug 2005, basi wrote:
>
>> Hello,
>> I'm a bit tired typing:
>>
>> if a == "" or a == nil
>> if a != "" and a !== nil
>>
>> I'm sure there is a Ruby way to do this.
>
>
> class NilClass
> def empty?
> true
> end
> end
>
> if a.empty?
>
I vote for this one because a good programmer is a lazy sod. Where ever
you would end up doing a thing more than once, write it is such a way that
you never have to type it again.
Austin Ziegler
Just, please, don't do it in a library that you unleash on the rest of
the world. It changes the contract for +nil+, and I prefer that it
*not* respond to #empty?, because the concept isn't *quite* accurate.
One may as well define #zero? if you're going to to that (but +nil+
isn't zero, either, just as it isn't the empty string or array).
Better is to use the foo.nil? or foo.empty? construct and be explicit,
or foo.to_s.empty? if you want to silently cast ("normalize").
Changing nil to respond to #empty? is an implicit change that also
changes its meaning.
-austin
--
Austin Ziegler * halos...@gmail.com
* Alternate: aus...@halostatue.ca
Wilson Bilkovich
Here's what it looks like:
# "", " ", nil, and 0 are all blank
def blank?
if respond_to?(:empty?) && respond_to?(:strip)
strip.empty?
elsif respond_to? :empty?
empty?
elsif respond_to? :zero?
zero?
else
!self
end
end
basi
Thanks all for the suggestions. This solution appeals to me because I
don't have to define anything new. I wonder if, in general, this is a
good criteria for evaluating solutions.
basi
Aredridel
> Thanks all for the suggestions. This solution appeals to me because I
> don't have to define anything new. I wonder if, in general, this is a
> good criteria for evaluating solutions.
Certainly not the only criteria one should use -- but it sure feels
right. It's the same reason I'd use an array, not some ContainerOfFoo
class that I define -- if the builtins do the job, use them!
James Edward Gray II
> Thanks all for the suggestions. This solution appeals to me because I
> don't have to define anything new. I wonder if, in general, this is a
> good criteria for evaluating solutions.
My two cents:
Ruby makes it trivially easy to alter the behavior of the core
classes. It's a powerful feature and I love it, but it's also easy
to abuse.
If you're working on a Domain Specific Language and want to alter the
core classes to fit that model, I say go for it. If you can add a
few methods to Array or String or whatever to help with the task you
are currently tackling, again I say do it.
However, I'm usually against hacks to change the behavior of the core
classes. You could break a lot of code that way, possibly in Ruby's
rich standard library. Plus, your teaching yourself to rely on non-
core techniques, which I doubt will help in the long run. Put in
terms of this thread, I'm fine with Rails' blank() method (just
adding some functionality), but leery of adding empty?() to nil
(that's not how Ruby's nil works).
Again though, that's all just my opinion. Obviously, Ruby allows
people to add empty?() to nil and some do.
James Edward Gray II
John Carter
> On 8/10/05, BearItAll <bear...@rassler.co.uk> wrote:
>> On Wed, 10 Aug 2005 14:44:15 +0900, John Carter wrote:
>>> class NilClass
>>> def empty?
>>> true
>>> end
>>> end
>>> if a.empty?
>> I vote for this one because a good programmer is a lazy sod. Where ever
>> you would end up doing a thing more than once, write it is such a way that
>> you never have to type it again.
>
> Just, please, don't do it in a library that you unleash on the rest of
> the world. It changes the contract for +nil+, and I prefer that it
> *not* respond to #empty?, because the concept isn't *quite* accurate.
Well...
I did say long and loud and tediously in the RCR 303 discussion that we
there are several meanings to nil and we need to change ruby to
distinguish between them.
The original poster had a NoThing type of nil. Your fear arises from the
possibility of applying the empty? method to an Unitialized or
NotApplicable type of nil.
David A. Black
On Thu, 11 Aug 2005, John Carter wrote:
> On Wed, 10 Aug 2005, Austin Ziegler wrote:
>
>> On 8/10/05, BearItAll <bear...@rassler.co.uk> wrote:
>>> On Wed, 10 Aug 2005 14:44:15 +0900, John Carter wrote:
>>>> class NilClass
>>>> def empty?
>>>> true
>>>> end
>>>> end
>>>> if a.empty?
>>> I vote for this one because a good programmer is a lazy sod. Where ever
>>> you would end up doing a thing more than once, write it is such a way that
>>> you never have to type it again.
>>
>> Just, please, don't do it in a library that you unleash on the rest of
>> the world. It changes the contract for +nil+, and I prefer that it
>> *not* respond to #empty?, because the concept isn't *quite* accurate.
>
> Well...
>
> I did say long and loud and tediously in the RCR 303 discussion that we there
> are several meanings to nil and we need to change ruby to distinguish between
> them.
>
> The original poster had a NoThing type of nil. Your fear arises from the
> possibility of applying the empty? method to an Unitialized or NotApplicable
> type of nil.
I would say that asking whether nil is empty is like asking whether 12
is empty: it just doesn't mean anything. Even having it say "false"
suggests that "true" is possible. In general, I don't think
non-container objects should be declaring themselves "empty".
Gavin Kistner
> On Aug 10, 2005, at 2:06 PM, basi wrote:
>> Thanks all for the suggestions. This solution appeals to me because I
>> don't have to define anything new. I wonder if, in general, this is a
>> good criteria for evaluating solutions.
> However, I'm usually against hacks to change the behavior of the
> core classes. You could break a lot of code that way, possibly in
> Ruby's rich standard library. Plus, your teaching yourself to rely
[snip]
This has been the biggest 'gotcha' for me; I started out with Ruby
and slowly grew my own library of really convenient (to me) additions/
changes to the core libraries. Invariably, I get to a point in my
code where I want to release it, and I'm left with three choices:
a) Require people to include my library-of-hacks (in whole, since I
don't have it broken into tiny pieces) if they want to use my sweet
new library I'm releasing. Not a nice dependency.
b) Copy/paste the salient hacks into my library file so they go along
together. Ugh, now I have a version control problem.
c) Rewrite my library not to use my own hacks, but instead strive to
use only built-in stuff.
Usually, I choose (c).
If you're doing programs just for yourself, I personally suggest you
do whatever makes your life easier. But the addiction to customizing
the language can be problematic if you want to share your code.
John Carter
>> The original poster had a NoThing type of nil. Your fear arises from the
>> possibility of applying the empty? method to an Unitialized or
>> NotApplicable type of nil.
>
> I would say that asking whether nil is empty is like asking whether 12
> is empty: it just doesn't mean anything. Even having it say "false"
> suggests that "true" is possible. In general, I don't think
> non-container objects should be declaring themselves "empty".
class Fixnum
def each
# I'm throwing this exception, not because it is required,
# but because a headache is damping my imagination
# as to what -1.each means. I think it means the something
# like collect or sum, but my head hurts too much to say.
raise "Negative number" if self < 0
(1..self).each{|i| yield 1}
end
def empty?
self == 0
end
end
12.each {|i| puts i}
1
1
1
1
1
1
1
1
1
1
1
1
What does NoThing contain?
Obvious it contains NoThing.
noThing.shift returns noThing.
Is NoThing empty?
Yes.
It's all like non-euclidean geometry. Nobody could prove Euclid's 5
postulate even though it was ugly enough to be a theorem not an axiom.
So some bright spark resolve to propose an alternative, intuitively wrong
alternative to postulate 5 and then find the contradiction.
There wasn't one.
ie. Equally valid non-euclidean geometries exist.
The current axioms of "nil" are valid and consistent.
But more useful, equally consistent axioms of "nil" can be proposed.
John Carter
> c) Rewrite my library not to use my own hacks, but instead strive to use only
> built-in stuff.
My whole reply was a little tease....
My Hidden Agenda was...
* Looky See, very very nice NullObject pattern solution to this problem.
* Wait for the chorus of Yums! As people see how simple and tasty it is.
* Wait for the echo of Yucks as curmudgeons like you correctly note the
downside.
* Pop up and say, "I told you so, we need to disambiguate the meanings of
nil!"
Unfortunately the poor newbie gets sorrowfully confused in the process.
Sorry mate.
David A. Black
On Thu, 11 Aug 2005, John Carter wrote:
> On Thu, 11 Aug 2005, David A. Black wrote:
>
>>> The original poster had a NoThing type of nil. Your fear arises from the
>>> possibility of applying the empty? method to an Unitialized or
>>> NotApplicable type of nil.
>>
>> I would say that asking whether nil is empty is like asking whether 12
>> is empty: it just doesn't mean anything. Even having it say "false"
>> suggests that "true" is possible. In general, I don't think
>> non-container objects should be declaring themselves "empty".
>
> class Fixnum
> def each
> # I'm throwing this exception, not because it is required,
> # but because a headache is damping my imagination
> # as to what -1.each means. I think it means the something
> # like collect or sum, but my head hurts too much to say.
> raise "Negative number" if self < 0
>
> (1..self).each{|i| yield 1}
> end
>
> def empty?
> self == 0
> end
> end
>
> 12.each {|i| puts i}
Well, yes, Ruby lets you do that. I would still argue that "it just
doesn't mean anything" :-) I don't think that 0 is empty.
Containers contain 0 elements are empty. 0 isn't a container.
> What does NoThing contain? Obvious it contains NoThing.
> noThing.shift returns noThing. Is NoThing empty? Yes.
This is a bit like "a ham sandwich is better than God" :-) [1] I'd
actually say there's a difference between: it contains [Nn]o[Tt]hing,
and: it's not a container.
> The current axioms of "nil" are valid and consistent. But more
> useful, equally consistent axioms of "nil" can be proposed.
I look at it the other way around: not "What can nil evolve to from
what it is?" but "Is it desireable to have an object that has
no dimensional characteristics (no size, no fullness or emptiness,
etc.)?" If it's good to have that, then it will either be nil or
whatever new term is created to replace nil if nil is changed. So I'd
just as soon keep nil nil and come up with something else if there's a
demonstrated need for something else.
Anyway, in practical terms I would certainly agree with Austin that
one should not change nil in any code that one plans to share.
David
[1] I don't where it originated, but the syllogism goes: A ham
sandwich is better than nothing. Nothing is better than God. Ergo...
Austin Ziegler
> On Wed, 10 Aug 2005, Austin Ziegler wrote:
>> On 8/10/05, BearItAll <bear...@rassler.co.uk> wrote:
>>> On Wed, 10 Aug 2005 14:44:15 +0900, John Carter wrote:
>>>> class NilClass
>>>> def empty?
>>>> true
>>>> end
>>>> end
>>>> if a.empty?
>>> I vote for this one because a good programmer is a lazy sod.
>>> Where ever you would end up doing a thing more than once, write
>>> it is such a way that you never have to type it again.
>> Just, please, don't do it in a library that you unleash on the
>> rest of the world. It changes the contract for +nil+, and I
>> prefer that it *not* respond to #empty?, because the concept
>> isn't *quite* accurate.
> that we there are several meanings to nil and we need to change
> ruby to distinguish between them.
I didn't go into detail there, John, but it's worth noting that
originally Codd thought that there should be several different NULL
values for relational databases. Later in life, he came to believe
that NULL values (both the single NULL value in SQL databases and
the multiple NULL values in his original relational papers) were
bad.
> The original poster had a NoThing type of nil. Your fear arises
> from the possibility of applying the empty? method to an
> Unitialized or NotApplicable type of nil.
Your proposal of multiple types of nil makes life harder. Instead
of:
if foo.nil?
# blah
end
I would have to do:
if foo.nothing? or foo.undefined? or foo.not_applicable?
# blah
end
The problem, as others have stated, is that adding #empty? to
NilClass implies a containment. I'd have as big a problem if we
added #empty? to Fixnum so that 0 returned true and everything else
returned false. (Indeed, would that be correct? Would -3.empty? be
true or false?)
Better to do:
if foo.nil? or foo.empty?
# blah
end
The code is explicit and meaningful at that point. Multiple types of
NULL/nil values tend to confuse things far more than they help
things.
John Carter
> I didn't go into detail there, John, but it's worth noting that
> originally Codd thought that there should be several different NULL
> values for relational databases. Later in life, he came to believe
> that NULL values (both the single NULL value in SQL databases and
> the multiple NULL values in his original relational papers) were
> bad.
No, as I remember it, his problem wasn't with NULL, but
rather the DB design.
ie. All instances where you have NotApplicable or NoThing null IN A
DB TABLE can be refactored to a better relational design that didn't
require them.
However, having factored the DB into more tables so neither variety of
NULL occurred, there is still a need for NULL. There is still a need on
occasion to construct reports for user display which are joins of various
tables. And in those "views" there may be some fields are going to be
NULL. And again, it is still necessary to disambiguate between
NotApplicable and NoThing.
> Your proposal of multiple types of nil makes life harder. Instead
> of:
>
> if foo.nil?
> # blah
> end
>
> I would have to do:
>
> if foo.nothing? or foo.undefined? or foo.not_applicable?
> # blah
> end
How about starting with the following in the core
class Object
# This is as is already
def nil?
false
end
def uninitialized?
false
end
def not_applicable?
false
end
def nothing?
false
end
end
class NilClass
# No change here
def nil?
true
end
def to_s
raise "No method, old definition inconsistent."
end
end
class NoThing < NilClass
def nothing?
true
end
def empty?
true
end
def to_s
""
end
def to_i
0
end
end
class NotApplicable < NilClass
def not_applicable?
true
end
end
class Uninitialize < NilClass
def uninitialized?
true
end
end
Now if the rest of the system chose the right version of nil when it
assigned nil to something, the problem would go away and we can extend the
NoThing in a sane harm free fashion.
> The problem, as others have stated, is that adding #empty? to
> NilClass implies a containment. I'd have as big a problem if we
> added #empty? to Fixnum so that 0 returned true and everything else
> returned false. (Indeed, would that be correct? Would -3.empty? be
> true or false?)
Tut! Tut! I'm having this same problem with my son at school, they teach
him the rote mechanics, but forget to teach the principles. (To be fair, I
only started learning these things when I start reading foundations of
mathematics type books from the university library...)
Come now, what is 3? 3 is 1+1+1. What do we mean by 1+1+1 we mean three
contains a 1 and a 1 and a 1! So if I extract the contents of three I get
1 and 1 and 1 back.
And -3? Surprise surprise it contains three minus ones!
There is a strong overlap between core system design and axiomatic
mathematics.
class FixNum
def empty?
self == 0
end
def length
self
end
def each
if self < 0
# -3 contains three minus ones...
(1..-self).each{|i| yield -1}
else # And 3 contains three ones.
(1..self).each{|i| yield 1}
end
end
end
William James
John Carter wrote:
> It's all like non-euclidean geometry. Nobody could prove Euclid's 5
> postulate even though it was ugly enough to be a theorem not an axiom.
By definition, axioms are not provable.
David A. Black
On Thu, 11 Aug 2005, Austin Ziegler wrote:
> The problem, as others have stated, is that adding #empty? to
> NilClass implies a containment. I'd have as big a problem if we
> added #empty? to Fixnum so that 0 returned true and everything else
> returned false. (Indeed, would that be correct? Would -3.empty? be
> true or false?)
I'd say it's undefined, or just meaningless. One could say that -3
"contains" three -1's... but I don't find that compelling. It could
be said, equally (and equally wrongly, in my view), to "contain" a 5
and a -8.
I don't consider something a container unless there's some meaning to
the concept of inserting, removing, counting, iterating over elements.
Even in the case of, say, a frozen array, there's still a meaning to
the concept of altering the collection. You can't remove a 1 from 3.
You can subtract 1 from 3, but that doesn't change 3. If it were
otherwise, then the expression "3 - 1" would turn 3 into 2, which
would cause lots of problems :-)
I would say that propagating the notion of emptiness to
non-collections definitely isn't the way to address nil-related
issues.
David
Florian Frank
Yes, but back then it wasn't known, that the 5th Euclidean axiom was
indead an axiom. That's why people tried to deduce it from the other
axioms - without success.
--
Florian Frank
Austin Ziegler
> On Thu, 11 Aug 2005, Austin Ziegler wrote:
>> I didn't go into detail there, John, but it's worth noting that
>> originally Codd thought that there should be several different
>> NULL values for relational databases. Later in life, he came to
>> believe that NULL values (both the single NULL value in SQL
>> databases and the multiple NULL values in his original relational
>> papers) were bad.
> No, as I remember it, his problem wasn't with NULL, but rather the
> DB design.
> ie. All instances where you have NotApplicable or NoThing null IN
> A DB TABLE can be refactored to a better relational design that
> didn't require them.
Um. In part, yes. The point is, though, that Codd believed toward
the end that multiple NULL values weren't nearly as useful as once
advocated.
> However, having factored the DB into more tables so neither
> variety of NULL occurred, there is still a need for NULL. There is
> still a need on occasion to construct reports for user display
> which are joins of various tables. And in those "views" there may
> be some fields are going to be NULL. And again, it is still
> necessary to disambiguate between NotApplicable and NoThing.
Is it? I don't think so, based on my experience. More often than
not, NULL -- whether "Not Applicable" or "No Thing" is blanked or
zeroed depending on the nature of the database.
>> Your proposal of multiple types of nil makes life harder. Instead
>> of:
>> if foo.nil?
>> # blah
>> end
>> I would have to do:
>> if foo.nothing? or foo.undefined? or foo.not_applicable?
>> # blah
>> end
> How about starting with the following in the core
[snip implementation of bad proposal]
It still expands the number of tests that we would ultimately have
to deal with for very questionable gain. You haven't convinced me
that the need for knowing the difference between a Nothing nil and
an Undefined nil, etc. is worth knowing. To be more specific, I have
not yet needed such a differentiation in ten years of professional
software development.
> Now if the rest of the system chose the right version of nil when
> it assigned nil to something, the problem would go away and we can
> extend the NoThing in a sane harm free fashion.
*shrug* I still don't think that it's valuable. Where's the Real
World Applicability?
>> The problem, as others have stated, is that adding #empty? to
>> NilClass implies a containment. I'd have as big a problem if we
>> added #empty? to Fixnum so that 0 returned true and everything
>> else returned false. (Indeed, would that be correct? Would
>> -3.empty? be true or false?)
> Tut! Tut! I'm having this same problem with my son at school, they
> teach him the rote mechanics, but forget to teach the principles.
> (To be fair, I only started learning these things when I start
> reading foundations of mathematics type books from the university
> library...)
> Come now, what is 3? 3 is 1+1+1. What do we mean by 1+1+1 we mean
> three contains a 1 and a 1 and a 1! So if I extract the contents
> of three I get 1 and 1 and 1 back.
> And -3? Surprise surprise it contains three minus ones!
> There is a strong overlap between core system design and axiomatic
> mathematics.
Um. No wonder you're having problems, if you are trying to teach him
things that aren't real. I'll be the first to admit that I'm weak,
but I don't recall arithmetic or numerical theory being based on set
theory (that is, numbers as sets).
John Carter
> Um. No wonder you're having problems, if you are trying to teach him
> things that aren't real. I'll be the first to admit that I'm weak,
> but I don't recall arithmetic or numerical theory being based on set
> theory (that is, numbers as sets).
http://mathworld.wolfram.com/OrdinalNumber.html
Kev Jackson
>> Um. No wonder you're having problems, if you are trying to teach him
>> things that aren't real. I'll be the first to admit that I'm weak,
>> but I don't recall arithmetic or numerical theory being based on set
>> theory (that is, numbers as sets).
>
>
> http://mathworld.wolfram.com/OrdinalNumber.html
>
single number line (according to my recollection),
reals/floats/engineering units are also a Set of values that exist on
this line (with them both exist the negative values), and for complex
numbers we have to expand into 2 dimensions. The Set theory of numbers
allows us to perform proof by induction (I think, it was a while ago) -
ie if something is true for n, then we can prove for n+1. I'm pretty
sure that was what 4 courses on (2)formal methods + mathematics +
algorithm design were trying to teach us - of course we were all
concentrating on the hot russian blonde in the front row! And I have to
admit to having never used this information professionally (hence it's
incredible rustiness), so I could be miles out. If so, sorry.
Kev
Devin Mullins
>> http://mathworld.wolfram.com/OrdinalNumber.html
>
> Yeah I have to agree here, integers are a Set of values based on a
> single number line (according to my recollection),
> reals/floats/engineering units are also a Set of values that exist on
> this line (with them both exist the negative values), and for complex
> numbers we have to expand into 2 dimensions.
Woah, woah, woah. Integers are just things that satisfy a specific set
of axioms. The cool Georgian definition is just one way of defining a
bunch of items that are Integers, as much as anything that satisfies
those axioms are Integers. Isomorphism is a wonderful thing.
Devin
Kev Jackson
> Woah, woah, woah. Integers are just things that satisfy a specific set
> of axioms. The cool Georgian definition is just one way of defining a
> bunch of items that are Integers, as much as anything that satisfies
> those axioms are Integers. Isomorphism is a wonderful thing.
Ok, agreed it's just one way of defining 'things' that happen to satisfy
a set of properties. The number line thing is a suitable image that can
be used to instruct young bored undergrads, but I think it's a helpful one .
Kev
David A. Black
> On Fri, 12 Aug 2005, Austin Ziegler wrote:
>
>> Um. No wonder you're having problems, if you are trying to teach him
>> things that aren't real. I'll be the first to admit that I'm weak,
>> but I don't recall arithmetic or numerical theory being based on set
>> theory (that is, numbers as sets).
>
> http://mathworld.wolfram.com/OrdinalNumber.html
Nothing on that page remotely implies that the Ruby Integer object 3
is a collection of three 1 objects, as you have claimed. In fact, the
elements of the ordinal number 3 are given clearly as {0,1,2}. But
even that doesn't matter because Ruby Integers are not ordinal numbers
in the first place.
Ruby Integers are integers. The whole concept of ordinal numbers is
explicitly and manifestly not about integers per se. As the page you
cite says, "an ordinal number...is one of the numbers in Georg
Cantor's extension of the whole numbers." Ruby Integers are not an
extension of the whole numbers. They're integers.
If you google for, say, "add two ordinals", or "negative ordinals",
you'll start to see even more clearly how irrelevant all of this is to
Integer objects.
More informative and relevant would be:
http://mathworld.wolfram.com/Integer.html[1] There's really no need to
cast about for something other than integers for Ruby Integers to be
like. If you want to write an OrdinalNumber class, you should. As
far as I know there isn't one yet.
David
[1] Eric W. Weisstein. "Integer." From MathWorld--A Wolfram Web
Resource.
daz
David A. Black wrote:
> On Thu, 11 Aug 2005, John Carter wrote:
>
> > What does NoThing contain? Obvious it contains NoThing.
> > noThing.shift returns noThing. Is NoThing empty? Yes.
>
> This is a bit like "a ham sandwich is better than God" :-) [1]
>
> David
>
> [1] I don't where it originated, but the syllogism goes: A ham
> sandwich is better than nothing. Nothing is better than God. Ergo...
>
"Nothing is better than eternal happiness.
A ham sandwich is better than nothing.
Therefore, a ham sandwich is better than eternal happiness."
- R. S. Nickerson.
(Reflections on reasoning. Erlbaum, Hillsdale NJ, 1986.)
Adam Sanderson
http://en.wikipedia.org/wiki/Mu_%28Japanese_word%29
Or for added entertainment just return nil again.
Oh wait, you didn't want to confuse the rest of the world?
.adam sanderson
Trans
contract of not responding to #empty? is going to cause a major
malfunction. If anyone is depending on #empty? to throw an error on a
errant nil result, they really need to reconsider their programming
strategy to begin with.
But that aside, there are other ways to intgerate polymorphic
charateristices between conceptually distinct classes. RoR's #blank? is
an example, albiet a lousy one, both in how it is defined and it's
semantic value. A better one that I have used is #to_b (akin to but
more fluid then to_bool):
class NilClass
def to_b ; false ; end
end
class String
def to_b ; !empty? ; end
end
And so on for the other classes.
Lastly, let me say that there is indeed a rasonable distinction between
two types of nil, and only two types. The first is the non-object
object. This is the typical use of Ruby's nil, it is a kind of filler,
or dummy object, often removed as in Array#compact. The other type is a
_nack_, a not-acknowledged object. Nack isn't a useful object in and of
itself. It does nothing more then communicate a message that something
is invalid or to be ignored. As such it would has no useful methods
other then those to raise the error for which it is essentially a
supression of. In fact the NackClass I designed was originally a
subclass of Exception (now it uses delegation instead for unrelated
reasons).
T.
Austin Ziegler
> Austin, I'd like to see a _real_ example of where NilClass' suppossed
> contract of not responding to #empty? is going to cause a major
> malfunction. If anyone is depending on #empty? to throw an error on a
> errant nil result, they really need to reconsider their programming
> strategy to begin with.
1. It isn't a supposed contract. By default, Ruby does not offer #empty?
on nil.
2. If an object does not respond to a message -- either through its
methods or its ancestral methods -- an exception will be thrown.
3. Software that uses #empty? in duck typing often expects that invalid
values won't respond to it but will, instead, throw an exception.
4. Most of the software that I've written in the last fourteen months
rather depends on #3. That's because I do everything I can to make
sure that the method is called with correct values; if it is not
called with a correct value, then I expect that an error will be
thrown.
This isn't a matter of needing to reconsider my programming strategy.
This is a matter of using the facilities which are available to me. It
gets worse if you accept Mr Carter's premise that +nil+ is better as an
"eater" object, because many things are NOT correct if a method is just
eaten and it is MORE correct to throw an exception than to produce
invalid data.
If you want something like this, use a new method. Make it clear. But
+nil+ isn't anything; therefore it can't be empty and it can't be
non-empty.
> Lastly, let me say that there is indeed a rasonable distinction
> between two types of nil, and only two types. The first is the
> non-object object. This is the typical use of Ruby's nil, it is a kind
> of filler, or dummy object, often removed as in Array#compact. The
> other type is a _nack_, a not-acknowledged object. Nack isn't a useful
> object in and of itself. It does nothing more then communicate a
> message that something is invalid or to be ignored. As such it would
> has no useful methods other then those to raise the error for which it
> is essentially a supression of. In fact the NackClass I designed was
> originally a subclass of Exception (now it uses delegation instead for
> unrelated reasons).
I disagree. The distinction between that which is +nil+ and that which
is +nack+ed merely adds complexity without adding significant meaning or
utility. Perl doesn't escape this in the least, with its "undef"
keyword.
Julian Leviston
The word nothing actually stand in place as a shortcut for a few
different meanings:
not anything (no things at all), not something (no particular thing
out of a set of things).
Also, we have this tendency in english to take the (what would be
succinct in meaning) negative out of the verb and either build it
into a noun or precede a noun with not someplace in our sentences. It
feels more human, natural and "flowing". The trouble with that is
that we potentially lose our meaning to vagueness. But ironically
enough, succinct meaning is usually pitted against "the flow of
things" or rather - it's one extreme side of the intersection between
flow and precision where usually people who insist on precision of
meaning lose the flow of things (as I have potentially just done
myself) ;-)
When reasoning, it's very important to be aware of your nouns, and to
expand your terms (ie meanings) ;-) However ironically the more
expanded your description / meanings / terms / words become, the less
people your audience includes - it excludes them through
complicatedness ;-).
"Not anything (the negative of all things) is better than eternal
happiness.
A ham sandwich is better than not something (no particular thing)
Therefore, there is no therefore .... ? :-)"
Julian.
On 17/08/2005, at 1:21 PM, daz wrote:
twi...@comcast.net
> happiness.
> A ham sandwich is better than not something (no particular thing)
> Therefore, there is no therefore .... ? :-)"
There is no thing that is better than eternal happiness.
There is no thing that a ham sandwich is better than.
Devin