To be clear - the proposal is NOT to make Ruby act like one of the many other languages where "", 0 and friends are treated as non-truth values in boolean expressions. The proposal is simply to add an additional method to all that allows a programmer to treat them the same in the few cases where that is desirable.
···
On Feb 22, 2005, at 7:32 AM, Gavin Kistner wrote:
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.
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.
On Feb 22, 2005, at 7:18 AM, David A. Black 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?
To be clear - the proposal is NOT to make Ruby act like one of the many other languages where "", 0 and friends are treated as non-truth values in boolean expressions. The proposal is simply to add an additional method to all that allows a programmer to treat them the same in the few cases where that is desirable.
As long as we are only proposing to add a new method then I am happy but
to be honest I think that the utility of this method will be very small
and the potential for confusion big. The difference will be subtle and
only visible in particular situations. I expect that it could become a
gotcha very quickly.
Even though I'm not sure I love globals like $\ or $*, I think the
"rule of validity" method should depend of a variable of that kind.
For instance, a global $- could be defined
and default to [nil, false, "", 0, , {}]. That way, one could define
at runtime wich values can be declared "vapid" or "empty" or whatever
the final method name is.
On Tue, 22 Feb 2005 23:37:37 +0900, Gavin Kistner <gavin@refinery.com> wrote:
On Feb 22, 2005, at 7:32 AM, Gavin Kistner wrote:
> 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.
>
> 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.
To be clear - the proposal is NOT to make Ruby act like one of the many
other languages where "", 0 and friends are treated as non-truth values
in boolean expressions. The proposal is simply to add an additional
method to all that allows a programmer to treat them the same in the
few cases where that is desirable.
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
Well, False has the value, or perhaps valuation, false. How about
Object#kinda_nilish?, giving it an informal name suggesting it's highly
informal nature? It would have the reverse interpretation of your
method, though...
nikolai (the comedian)
···
--
::: 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);}
(In response to news:41EFDE9C-84DF-11D9-8B41-0011243148CC@refinery.com by
Gavin Kistner)
To be clear - the proposal is NOT to make Ruby act like one of the many
other languages where "", 0 and friends are treated as non-truth values
in boolean expressions. The proposal is simply to add an additional
method to all that allows a programmer to treat them the same in the
few cases where that is desirable.
I can't see why this method should be added to all of Ruby.. it seems to
apply to a special case you need to handle. You know, it is perfectly ok to
change stdlib just for your project... this is what Ruby is about.
I feel very at home with the distinction between empty and nil that is made
currently. In the case of financial data that may have empty cells I would
propose to add a small class layer between that has an empty? method.. thus
solving the problem in an app specific way and not changing the language.
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.
100% agree. I especially cannot understand (at least mathematically) why 0 would be empty and 1 not.
(...)
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.
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.
To be clear - the proposal is NOT to make Ruby act like one of the many other languages where "", 0 and friends are treated as non-truth values in boolean expressions. The proposal is simply to add an additional method to all that allows a programmer to treat them the same in the few cases where that is desirable.
FWIW, I once suggested the name "null?" for this.
I've always been perturbed that there is no good word which
means non-nil or non-null. A positive should be representable
as something other than a double negative IMO.
In Cantor-style Set Theory, the Naturals usually get redefined in such a
way that 0 is equal to the empty set. Which means, incidentally, that 0
_is_ the empty set, and vice versa.
That definition is quite popular in Logic, but fails to draw much usage in
the rest of Mathematics. It's not the only definition either. Dedekind's
definition implies 0 is the set of all rationals lower than 0. Those
multiple defs can be thought of as different implementations, while the
usually-used interface consists of the operators +,-,*,/,etc.
In computer science, the first definition would be the most accepted of
the two, simply because the latter involves Real Numbers, which don't
exist in reality, by Skölem's Paradox. This may exclude the many lost
souls who don't get math, such Niklaus Wirth, who gave the name of Real to
a floating-point type (!!!) in PASCAL.
(If you think some programmers have bad naming skills when it comes to
writing their programs, find who called the Real Numbers "Real", when
almost all elements of that set don't exist.)
···
On Tue, 22 Feb 2005, Michael Neumann wrote:
100% agree. I especially cannot understand (at least mathematically) why
0 would be empty and 1 not.
This, or something like it, would be useful for the case where I have to do:
foo if bar.nil? or bar.empty?
foo(bar) if bar and not bar.empty?
It's not common, but it is common enough. I want to sometimes write it as:
foo if bar.empty?
...because for the purposes of what I'm doing (I think that this is in
Text::Format), +nil+ is as good as empty.
-austin
···
On Wed, 23 Feb 2005 00:32:02 +0900, Kaspar Schiess <eule@space.ch> wrote:
I can't see why this method should be added to all of Ruby.. it seems to
apply to a special case you need to handle. You know, it is perfectly ok to
change stdlib just for your project... this is what Ruby is about.
I feel very at home with the distinction between empty and nil that is made
currently. In the case of financial data that may have empty cells I would
propose to add a small class layer between that has an empty? method.. thus
solving the problem in an app specific way and not changing the language.
That guy who has a paradox, is simply Skolem, without the umlaut.
But, afaik, Skolem paradox is the phenomena that (provided set theory is
consistent) it has a countable model; on the other hand, set theory
knows of arbitrarily large cardinalities -- how can all that stuff fit
into a simple countable universe?
I wouldn't even call it a paradox: if you know the proper meaning of the
notions being involved, you'll see how it's possible. It just sounds
weird.
Comme ci, comme ca, how can you arrive to ontological claims from this
point? Speaking of existence is a marshy area in mathematics everywhere
beyond finiteness. In what sense does the set of all natural numbers
exist? From the consensual statement that 1, 2, 3, and so on, all exist,
you can't just jump there and claim, "there is a set of all natural
numbers". Similarly you can ask, in what sense do real numbers and their
set exist?
Note that again, existence of individual reals and their set is quite a
different problem. At least, the existence of their set. Denying the
latter doesn't imply denying the former. Intutively, a real number is
at about the same level of complexity as the set of natural numbers (as
a real between 0 and 1 can be specified by a set of natural numbers: the
indices where you have 1 in its binary representation; it's easy to
extend to all reals); but their set it at "one level higher".
All these considerations don't give an answer to the questions of
existence. In fact, what can answer to such a question is nothing but
your preconceptions And that's fine, they are just better kept far
from mathematics. Mathematicians don't need anything non-consensual
involved into the game. This is why you don't hear them speaking up in
such issues.
Csaba
···
On 2005-02-26, Mathieu Bouchard <matju@sympatico.ca> wrote:
In computer science, the first definition would be the most accepted of
the two, simply because the latter involves Real Numbers, which don't
exist in reality, by Skölem's Paradox. This may exclude the many lost
souls who don't get math, such Niklaus Wirth, who gave the name of Real to
a floating-point type (!!!) in PASCAL.
I'm pretty new to ruby, so may have this wrong, but if you're
expecting nil or an empty string, can you not do bar.to_s.empty? and
as nil.to_s == "" it'll return true for nil or an empty string.
so:
foo if bar.to_s.empty?
foo(bar) unless bar.to_s.empty?
Chris
···
On Wed, 23 Feb 2005 02:22:45 +0900, Austin Ziegler <halostatue@gmail.com> wrote:
On Wed, 23 Feb 2005 00:32:02 +0900, Kaspar Schiess <eule@space.ch> wrote:
> I can't see why this method should be added to all of Ruby.. it seems to
> apply to a special case you need to handle. You know, it is perfectly ok to
> change stdlib just for your project... this is what Ruby is about.
>
> I feel very at home with the distinction between empty and nil that is made
> currently. In the case of financial data that may have empty cells I would
> propose to add a small class layer between that has an empty? method.. thus
> solving the problem in an app specific way and not changing the language.
This, or something like it, would be useful for the case where I have to do:
foo if bar.nil? or bar.empty?
foo(bar) if bar and not bar.empty?
It's not common, but it is common enough. I want to sometimes write it as:
foo if bar.empty?
...because for the purposes of what I'm doing (I think that this is in
Text::Format), +nil+ is as good as empty.
Caio Tiago Oliveira wrote:
> Michael Neumann, 22/2/2005 11:25:
>> 100% agree. I especially cannot understand (at least mathematically)
>> why 0 would be empty and 1 not.
>> (...)
>
>
> Binary logic, 0 is false, 1 is true.
In fact, those are actual symbols and not numbers!
exactly! This issue seems to come up on the ML from time to time. I
voiced my opinion that Smalltalk conditionals (depending on behavior)
are much better than depending on value (check for nil or false). It
can be tailored to fit any object easily... but I think the idea lost
out to people who would rather keep ruby more of that same and
probably a little faster (though there are some things ruby can't do
because of this). My vote is still up for .true? {} and .false? {}
I really don't care if you guys agree or not but it sure is elegant.
Ruby is already a very good language so I am happy anyhow.
Regards,
Michael
Brian.
···
On Wed, 23 Feb 2005 03:00:03 +0900, Michael Neumann <mneumann@ntecs.de> wrote:
(In response to news:9e7db91105022209227c70832e@mail.gmail.com by Austin
Ziegler)
...because for the purposes of what I'm doing (I think that this is in
Text::Format), +nil+ is as good as empty.
I know the situtation (from Text::Reform ;)) and have thought rather
differently about it:
If your representation of things stings you, why don't change the
representation itself ? As in:
class StringValue < String
def initialize str
self.replace str || ''
end
end
Untested code that does not by itself solve the problem. But my point is:
thinking about the good wrapper for data will.
I certainly don't think a special case like this needs to be promoted
downwards into the language. What we just might want to do is make a list
of things that return nil instead of '' where '' would be more
appropriate. And then probably think about changing these methods.
I didn't like the #vapid suggestion at the start, but now I am starting
to rather like it.. Except for the added language complexity.
100% agree. I especially cannot understand (at least mathematically)
why 0 would be empty and 1 not.
(...)
Binary logic, 0 is false, 1 is true.
In fact, those are actual symbols and not numbers!
exactly! This issue seems to come up on the ML from time to time. I
voiced my opinion that Smalltalk conditionals (depending on behavior)
are much better than depending on value (check for nil or false). It
can be tailored to fit any object easily... but I think the idea lost
out to people who would rather keep ruby more of that same and
probably a little faster (though there are some things ruby can't do
because of this). My vote is still up for .true? {} and .false? {}
I really don't care if you guys agree or not but it sure is elegant.
Ruby is already a very good language so I am happy anyhow.
At least for .nil? I agree. I am not sure whether I'd like to write
"if a.true?" all the time. Nevertheless I believe that
if a.false?
is clearer to read and understand than:
if not a
Just because human mind if very bad at negating conditions (proven by studies of some psychologists).
Regards,
Michael
···
On Wed, 23 Feb 2005 03:00:03 +0900, Michael Neumann <mneumann@ntecs.de> wrote:
100% agree. I especially cannot understand (at least mathematically)
why 0 would be empty and 1 not.
(...)
Binary logic, 0 is false, 1 is true.
In fact, those are actual symbols and not numbers!
exactly! This issue seems to come up on the ML from time to time. I
voiced my opinion that Smalltalk conditionals (depending on behavior)
are much better than depending on value (check for nil or false). It
can be tailored to fit any object easily... but I think the idea lost
out to people who would rather keep ruby more of that same and
probably a little faster (though there are some things ruby can't do
because of this). My vote is still up for .true? {} and .false? {}
I really don't care if you guys agree or not but it sure is elegant.
Ruby is already a very good language so I am happy anyhow.
At least for .nil? I agree. I am not sure whether I'd like to write
"if a.true?" all the time. Nevertheless I believe that
I don't think the proposal was to replace if a with if a.true? but rather to replace
if a
code
end
with
a.true? { code }
if a.false?
is clearer to read and understand than:
if not a
likewise this would be
a.false? { code }
which is the way that Smalltalk works
···
On Wed, 23 Feb 2005 03:00:03 +0900, Michael Neumann >> <mneumann@ntecs.de> wrote:
Just because human mind if very bad at negating conditions (proven by studies of some psychologists).
Brian Mitchell wrote:
>
>>Caio Tiago Oliveira wrote:
>>
>>>Michael Neumann, 22/2/2005 11:25:
>>>
>>>>100% agree. I especially cannot understand (at least mathematically)
>>>>why 0 would be empty and 1 not.
>>>>(...)
>>>
>>>
>>>Binary logic, 0 is false, 1 is true.
>>
>>In fact, those are actual symbols and not numbers!
>
>
> exactly! This issue seems to come up on the ML from time to time. I
> voiced my opinion that Smalltalk conditionals (depending on behavior)
> are much better than depending on value (check for nil or false). It
> can be tailored to fit any object easily... but I think the idea lost
> out to people who would rather keep ruby more of that same and
> probably a little faster (though there are some things ruby can't do
> because of this). My vote is still up for .true? {} and .false? {}
>
>
>
> I really don't care if you guys agree or not but it sure is elegant.
> Ruby is already a very good language so I am happy anyhow.
At least for .nil? I agree. I am not sure whether I'd like to write
"if a.true?" all the time. Nevertheless I believe that
Not quite what I meant... I left my post short as I have posted this a
few times before...
if a
puts "true"
end
would be what you write but it would be the equivalent of
a.true? {
puts "true"
}
but not actually written that way (syntax sugar).
This seems messy and confusing but is really nice when meta
programming. One area that could easily benefit from this is DSLs in
Ruby. Another would be creation of higher order logic like fuzzy logic
or lazy evaluation logic and so on. You could even write some bad code
with this but Ruby has never been a watch over your sholder language
as plenty of things like this already exists. It is up to the
porgrammer to use it right. Now to confuse some people:
class Both
def true?
yield
end
def false?
yield
end
end
a = Both.new
a? 1 : 2 # What does this return? probably 2 but it is one grey area
to be aware of.
# or what if a was changed to yield on false? while executing part "1"
but it was not that way before the test.
This is extremely dynamic so it would probably slow ruby down rather
than speed ruby up.
if a.false?
is clearer to read and understand than:
if not a
Just because human mind if very bad at negating conditions (proven by
studies of some psychologists).
Regards,
Michael
Brian.
···
On Wed, 23 Feb 2005 03:54:16 +0900, Michael Neumann <mneumann@ntecs.de> wrote:
> On Wed, 23 Feb 2005 03:00:03 +0900, Michael Neumann <mneumann@ntecs.de> wrote:
