The following was derived from a portion of the destrutive! operations thread.
Here is a proposal for evaluating "", 0, and nil in an if statement:
Add empty? to NilClass and Fixnum
class NilClass
def empty?
true
end
end
class Fixnum
def empty?
self == 0 ? true : false
end
end
nil.empty? => true
0.empty? => true
These already exist:
"".empty? => true
[].empty? => true
{}.empty? => true
Dan
Hi,
Am Dienstag, 22. Feb 2005, 20:49:51 +0900 schrieb Dan Fitzpatrick:
The following was derived from a portion of the destrutive! operations
thread.Here is a proposal for evaluating "", 0, and nil in an if statement:
Add empty? to NilClass and Fixnum
nil.empty? => true
0.empty? => trueThese already exist:
"".empty? => true
.empty? => true
{}.empty? => true
Maybe even "true.empty? #=> true", "false.empty? #=> false"?
A good chance to end the discussions started over and over
about strings and numbers in `if' clauses, I think.
Bertram
--
Bertram Scharpf
Stuttgart, Deutschland/Germany
http://www.bertram-scharpf.de
Here is a proposal for evaluating "", 0, and nil in an if statement:
I'd be pretty happy to see that happen. It would make especially Ruby in view logic a lot easier to deal with.
--
David Heinemeier Hansson,
http://www.basecamphq.com/ -- Web-based Project Management
http://www.rubyonrails.org/ -- Web-application framework for Ruby
http://www.loudthinking.com/ -- Broadcasting Brain
Hi --
On Tue, 22 Feb 2005, Dan Fitzpatrick wrote:
The following was derived from a portion of the destrutive! operations thread.
Here is a proposal for evaluating "", 0, and nil in an if statement:
Add empty? to NilClass and Fixnum
class NilClass
def empty?
true
end
endclass Fixnum
def empty?
self == 0 ? true : false
end
end
Or:
class Fixnum
alias :empty? :zero?
end
David
--
David A. Black
dblack@wobblini.net
Bertram Scharpf wrote:
Hi,
The following was derived from a portion of the destrutive! operations thread.
Here is a proposal for evaluating "", 0, and nil in an if statement:
Add empty? to NilClass and Fixnum
nil.empty? => true
0.empty? => trueThese already exist:
"".empty? => true
.empty? => true
{}.empty? => true
Maybe even "true.empty? #=> true", "false.empty? #=> false"?A good chance to end the discussions started over and over
about strings and numbers in `if' clauses, I think.Bertram
I would reverse the true and false:
true.empty? => false
false.empty? => true
These are not quite as intuitive as NilClass and Fixnum but I agree they would be nice to have as well.
Dan
Am Dienstag, 22. Feb 2005, 20:49:51 +0900 schrieb Dan Fitzpatrick:
David Heinemeier Hansson wrote:
Here is a proposal for evaluating "", 0, and nil in an if statement:
I'd be pretty happy to see that happen. It would make especially Ruby in view logic a lot easier to deal with.
But please please use a different name than "empty?", maybe "nothing?" or "something?" or whatever else.
Regards,
Michael
David Heinemeier Hansson schrieb:
Here is a proposal for evaluating "", 0, and nil in an if statement:
I'd be pretty happy to see that happen. It would make especially Ruby in view logic a lot easier to deal with.
Could anyone post examples of actual code that would be easier if 0 had a special property in common with nil and ""? I think I never needed this in Ruby.
Regards,
Pit
I don't have actual code, but imagine looping through records returned with financial data, and you want to print out a "-" if the field is missing -or- zero. The whole "this field doesn't have any meaningful information that contributes to the sum of the column" spreadsheet thing.
I would support an RCR with this proposal, under just about any method name 
And I agree, boolean types need the same method as well.
On Feb 22, 2005, at 6:41 AM, Pit Capitain wrote:
David Heinemeier Hansson schrieb:
Here is a proposal for evaluating "", 0, and nil in an if statement:
I'd be pretty happy to see that happen. It would make especially Ruby in view logic a lot easier to deal with.
Could anyone post examples of actual code that would be easier if 0 had a special property in common with nil and ""? I think I never needed this in Ruby.
* Dan Fitzpatrick (Feb 22, 2005 14:00):
true.empty? => false
false.empty? => true
These are not quite as intuitive as NilClass and Fixnum but I agree they
would be nice to have as well.
How is 0 empty? 0 is a number representing nothing; it's not empty.
How is nil empty? It's nothing, thus it can't be empty.
A string is a container of symbols/character. A string containing no
symbols/characters is empty.
An array or a hashtable is a container of elements/items. An array or a
hashtable containing no elements/items is empty.
Stop equating and nil. Ruby is thankfully not PHP,
nikolai
--
::: name: Nikolai Weibull :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
::: page: www.pcppopper.org :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
I think it was a joke, but why not #vapid? -- it came from the spawning thread.
-austin
On Tue, 22 Feb 2005 22:24:18 +0900, Michael Neumann <mneumann@ntecs.de> wrote:
David Heinemeier Hansson wrote:
>> Here is a proposal for evaluating "", 0, and nil in an if statement:
> I'd be pretty happy to see that happen. It would make especially Ruby in
> view logic a lot easier to deal with.
But please please use a different name than "empty?", maybe "nothing?"
or "something?" or whatever else.
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca
Michael Neumann wrote:
But please please use a different name than "empty?", maybe "nothing?"
or "something?" or whatever else.
How about "piningforcplusplus?" 
J. Lambert
As I responded in the destructive! thread, if people are opposed to the term "empty?", then what about the sort of fun name of "vapid?" instead?
vap-id
adj.
1. Lacking liveliness, animation, or interest; dull: vapid conversation.
2. Lacking taste, zest, or flavor; flat: vapid beer.
We're not actually denigrating the value so far as to call it empty or useless, but simply stating that it's one that we commonly aren't interested in. (Although to be precise, I suppose we tend to be interested in these values specifically because they are so different from all the others...it's just that it's only the others that we care about
0.vapid? #=> true
"".vapid? #=> true
.vapid? #=> true
{}.vapid? #=> true
false.vapid? #=> true
nil.vapid? #=> true
On Feb 22, 2005, at 6:47 AM, Gavin Kistner wrote:
I would support an RCR with this proposal, under just about any method name
--
(-, /\ \/ / /\/
Gavin Kistner wrote:
I don't have actual code, but imagine looping through records returned with financial data, and you want to print out a "-" if the field is missing -or- zero. The whole "this field doesn't have any meaningful information that contributes to the sum of the column" spreadsheet thing.
Might this not cause trouble with databases. A database record (returned
as a structure or object) would have NULL == nil for fields with no
value which is not the same as a field with a definite value such as 0.
* Gavin Kistner (Feb 22, 2005 14:50):
I don't have actual code, but imagine looping through records returned
with financial data, and you want to print out a "-" if the field is
missing -or- zero. The whole "this field doesn't have any meaningful
information that contributes to the sum of the column" spreadsheet
thing.
How is a yearly/monthly/weekly/daily/whatever revenue of $0 not
meaningful information? Poor example I'm sure, but yours wasn't much
better.
I would support an RCR with this proposal, under just about any method
name
Wow. I wonder what George Boole would say if he heard that his logic
was being abused in this manner.
Boolean values are either true or false. They don't have an inherit
property dictating whether they are empty or non-empty. Sets may be
empty or non-empty,
nikolai (the smug bastard)
--
::: name: Nikolai Weibull :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
::: page: www.pcppopper.org :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
Gavin Kistner schrieb:
I don't have actual code, but imagine looping through records returned with financial data, and you want to print out a "-" if the field is missing -or- zero. The whole "this field doesn't have any meaningful information that contributes to the sum of the column" spreadsheet thing.
I would support an RCR with this proposal, under just about any method name
And I agree, boolean types need the same method as well.
When dealing with financial data, you often have to calculate the product of a couple of values: v1 * v2 * v3 * ... Here, the number, that "doesn't have any meaningful information that contributes to the PRODUCT of the column", is 1. I think you can find many examples where the number 0 is special, but you can also find examples where another number is special.
Regards,
Pit
Hi --
I would support an RCR with this proposal, under just about any method name
As I responded in the destructive! thread, if people are opposed to the term "empty?", then what about the sort of fun name of "vapid?" instead?
It's arguably exactly the opposite of what you'd want -- namely, to
point up the singularity of 0/""/etc., not their ordinariness. 37534
is more vapid than 0
I'm not sold on this anyway. I think it would have the flavor of
"added on to the language as an afterthought". .zero? means the
object is zero, and .empty? means a container object is empty. I
don't think cross-breeding them retains the logic.
David
On Tue, 22 Feb 2005, Gavin Kistner wrote:
On Feb 22, 2005, at 6:47 AM, Gavin Kistner wrote:
--
David A. Black
dblack@wobblini.net
Yes, there are many cases where you DO want to distinguish between nil and 0. These cases are already handled by the current behavior of Ruby.
It's just that there are also other cases where you want 0, nil, "", false, , and {} to all behave the same way. (Perhaps not a single use case that encompasses all of those, but certainly cases like the above where you want to know "Is there a value in here that I care about, or not?" without having to test the klass or duck type it.)
Consider a method that returns either an array of matches, or nil, but sometimes returns an empty array. Wouldn't it be nicer to be able to do something like:
unless obj.foo.vapid?
...
end
instead of something like:
val = obj.foo
if val && !val.empty?
...
end
(and yes, you can probably golf with that to make it more terse)
The problem gets worse as you start dealing with arguments passed to your methods, and your desire to be really flexible about what types of values you accept.
On Feb 22, 2005, at 7:19 AM, Peter Hickman wrote:
I don't have actual code, but imagine looping through records returned with financial data, and you want to print out a "-" if the field is missing -or- zero. The whole "this field doesn't have any meaningful information that contributes to the sum of the column" spreadsheet thing.
Might this not cause trouble with databases. A database record (returned
as a structure or object) would have NULL == nil for fields with no
value which is not the same as a field with a definite value such as 0.
In Logic, a Boolean Algebra has 2**n elements, so a Boolean value may have
n bits. I don't know what Boole would say if he found out his name has
been used for a thing that has only 1 bit. A n-bit Boolean Algebra is
about equivalent to a n-dimensional vector space of 1-bit Boolean
Algebras.
There are definitions of Booleans as Sets as well. One easy is that a
Boolean is a Set of the indices that are in the "true" state in itself. In
that sense, false is empty.
Another definition is to instead use the set of all elements that are
"less than or equal" to itself, where "less than or equal to", A <= B, is
defined as A&B == A.
On Wed, 23 Feb 2005, Nikolai Weibull wrote:
> I would support an RCR with this proposal, under just about any method
> nameWow. I wonder what George Boole would say if he heard that his logic
was being abused in this manner. Boolean values are either true or
false. They don't have an inherit property dictating whether they are
empty or non-empty.
_____________________________________________________________________
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
David A. Black wrote:
Hi --
I would support an RCR with this proposal, under just about any method name
As I responded in the destructive! thread, if people are opposed to the term "empty?", then what about the sort of fun name of "vapid?" instead?
It's arguably exactly the opposite of what you'd want -- namely, to
point up the singularity of 0/""/etc., not their ordinariness. 37534
is more vapid than 0I'm not sold on this anyway. I think it would have the flavor of
"added on to the language as an afterthought". .zero? means the
object is zero, and .empty? means a container object is empty. I
don't think cross-breeding them retains the logic.
100% agree. I especially cannot understand (at least mathematically) why 0 would be empty and 1 not.
Why not simply define a has_value? method:
def has_value?(obj)
case obj
when Enumerable
!obj.empty?
when NilClass, FalseClass
false
when TrueClass
true
when Integer
!obj.zero?
else
# do what you want
obj.respond_to?(...)
...
end
end
This probably serves most needs...
Regards,
Michael
On Tue, 22 Feb 2005, Gavin Kistner wrote:
On Feb 22, 2005, at 6:47 AM, Gavin Kistner wrote:
It's arguably exactly the opposite of what you'd want -- namely, to
point up the singularity of 0/""/etc., not their ordinariness. 37534
is more vapid than 0
Aye, it is arguably so. But I think having a method name of
my_var.is_super_special_because_it_is_so_boring?
might be annoying to type
I'm not sold on this anyway.
I'm confused, which are you not sold on - the name "vapid" or the concept of adding a common method across many objects that supports the use cases where you need to treat their 'empty' values the same?
On Feb 22, 2005, at 7:18 AM, David A. Black wrote: