Greetings!
I am wondering why there are two separate classes (TrueClass and
FalseClass) to deal with boolean types insead of one class (something
like Boolean?). Do you know
why the library designer desided to use this approach?
Your help will be greatly apreciated.
Thanks
--
Posted via http://www.ruby-forum.com/.
This has been discussed many, many times before. Here's a reading list:
On Mar 30, 2006, at 1:31 PM, PrimaryKey wrote:
Greetings!
I am wondering why there are two separate classes (TrueClass and
FalseClass) to deal with boolean types insead of one class (something
like Boolean?). Do you know
why the library designer desided to use this approach?Your help will be greatly apreciated.
--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
Since everything in ruby is an object, there need to be objects for
representing true and false. Once you have those, why do you need a
Boolean class?
PrimaryKey wrote:
Greetings!
I am wondering why there are two separate classes (TrueClass and
FalseClass) to deal with boolean types insead of one class (something
like Boolean?). Do you know
why the library designer desided to use this approach?Your help will be greatly apreciated.
Thanks
--
Posted via http://www.ruby-forum.com/\.
PrimaryKey wrote:
I am wondering why there are two separate classes (TrueClass and FalseClass) to deal with boolean types insead of one class (something like Boolean?). Do you know
why the library designer desided to use this approach?
I think it is because true and false don't really have anything in common in Ruby. No way to share code.
You can always fix it pretty easily:
module Boolean; end
[true, false].each do |obj|
obj.extend(Boolean)
end
true.is_a?(Boolean) # => true
false.is_a?(Boolean) # => true
But note that in Ruby all objects (except false and nil) can be used as true values. And they are used for just that even in the standard library.
"baumanj@gmail.com" <baumanj@gmail.com> writes:
Since everything in ruby is an object, there need to be objects for
representing true and false. Once you have those, why do you need a
Boolean class?
if a.kind_of? Boolean
case y
when Integer
when Boolean
end
I often wanted this shortcut...
--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org
case y
when Integer
when TrueClass,FalseClass
end
works ok, right? I kind of wish the class names were just True and False.
Gary Wright
On Mar 31, 2006, at 9:27 AM, Christian Neukirchen wrote:
case y
when Integer
when Boolean
end
indeed. i tend to use
case obj
when Klass
when TrueClass, FalseClass
end
which is ugly.
another thing a real Boolean class could give is a 'maybe' obj such that
maybe or true -> maybe
maybe or true and false or true -> maybe
maybe and false -> maybe
although i can't think of anything attm to do with this it would undoubtably
lead to some nice logical constructs that more closely parallel the way we
think.
i've brought this up once or twice before - maybe we should just put together
a patch and send to ruby-core?
regards.
-a
On Fri, 31 Mar 2006, Christian Neukirchen wrote:
"baumanj@gmail.com" <baumanj@gmail.com> writes:
Since everything in ruby is an object, there need to be objects for
representing true and false. Once you have those, why do you need a
Boolean class?if a.kind_of? Boolean
case y
when Integer
when Boolean
endI often wanted this shortcut...
--
share your knowledge. it's a way to achieve immortality.
- h.h. the 14th dali lama
> if a.kind_of? Boolean
>
> case y
> when Integer
> when Boolean
> end
What kind of scenarios would you want to use such a construct? It seems
to me not very rubyish to be switching based on the class of an object.
As I understand it, the more conventional way to deal with potentially
diverse argument types is to use the respond_to? method. This keeps the
door open for duck typing.
another thing a real Boolean class could give is a 'maybe' obj such that
....
although i can't think of anything attm to do with this it would undoubtably
lead to some nice logical constructs that more closely parallel the way we
think.
It sounds like you're talking about a sort of restricted fuzzy logic,
which is very cool, but is not appropriate for the core of a general
purpose language. Considering that every expression can be interpreted
in a boolean context, what would a maybe value do? Either behavior
seems wrong.
ara.t.howard@noaa.gov wrote:
On Fri, 31 Mar 2006, Christian Neukirchen wrote:
unknown wrote:
maybe or true -> maybe
Wouldn't maybe or true be true?
Shouldn't this be false?
{true, false} and false is going to be false regardless of what maybe is
On Mar 31, 2006, at 10:21 AM, ara.t.howard@noaa.gov wrote:
maybe and false -> maybe
gwtmp01@mac.com wrote:
case y
when Integer
when Boolean
endcase y
when Integer
when TrueClass,FalseClass
end
You could always assign some new constants to them:
True = TrueClass
False = FalseClass
case y
when Integer
when True, False
end
On Mar 31, 2006, at 9:27 AM, Christian Neukirchen wrote:
--
John Long
http://wiseheartdesign.com
another thing a real Boolean class could give is a 'maybe' obj such that
maybe or true -> maybe
maybe or true and false or true -> maybe
maybe and false -> maybe
What whould this do
print "hello" if maybe
or this
while maybe
print "hello"
end
// Niklas
if a.kind_of? Boolean
case y
when Integer
when Boolean
endWhat kind of scenarios would you want to use such a construct? It seems to
me not very rubyish to be switching based on the class of an object. As I
understand it, the more conventional way to deal with potentially diverse
argument types is to use the respond_to? method. This keeps the door open
for duck typing.
i generally do use duck typing, but sometimes it is simply not appropriate or
become too verbose. for example, consider a matrix class with the following
behaviour
1d
m[true] #=> all data returned
m #=> all data returned
m[true] = elems #=> data along all dims set
m = elems #=> data along all dims set
m[int] #=> treat as 1d array, return elem
m[int] = elem #=> treat as 1d array, set idx to elem
m[off, len] #=> treat as 1d array, return elems off thru len
m[off, len] = elem #=> treat as 1d array, set elems off thru len to elem
m[a .. b] #=> treat as 1d array, return elems in range
m[a .. b] = elem #=> treat as 1d array, set elems in range to elem
m[n] #=> idx one matrix by another
2d
generalize all above so multiple indices access in multi-dimensional
fashion. eg
m[0,1,2] #= return idx x,y,z
m[0,30..42,true] #= return column 0, rows 30 to 42, in all height dims
now, in case you are thinking that i'm just being difficult, this is exactly
how the narray class works
http://narray.rubyforge.org/SPEC.en
have fun writing that with respond_to? !! 
also, when working with concrete data structures (like binary output from C
programs) it's often quite sufficient to have a type mapping. further more
it's sometimes critical, for instace writing the word located at offset=42,
len=4 with a packed int value or sending a given sequence of bytes down a
socket that a given type is used and it's much more natural to write
def send buf, which = nil
case which
when Fixnum
socket.write [which].pack('N')
socket.write buf
when NilClass
socket.write [buf.size].pack('N')
socket.write buf
when Range
length = which.last - which.first
socket.write [length].pack('N')
socket.write buf[which]
else
raise TypeError, which.class
end
end
than something using respond_to?.
don't get me wrong - i defintely advocate duck typing, but when the number of
possible input types becomes large and behaviour is different depending on
that type it becomes cumbersome. this is the price we pay for not having c--
style polymorphism. in fact, it's very common to see the two styles combined:
case arg
when Fixnum
...
when Range
...
else # dunno - assume String and use in a duck type fashion
end
another thing a real Boolean class could give is a 'maybe' obj such that
....
although i can't think of anything attm to do with this it would undoubtably
lead to some nice logical constructs that more closely parallel the way we
think.It sounds like you're talking about a sort of restricted fuzzy logic, which
is very cool, but is not appropriate for the core of a general purpose
language. Considering that every expression can be interpreted in a boolean
context, what would a maybe value do? Either behavior seems wrong.
i disagree - ruby (and hardware) already supports this style of logic in
several ways:
harp:~ > irb
irb(main):001:0> nan = 0.0/0.0
=> NaN
irb(main):002:0> nan * 42
=> NaN
irb(main):003:0> nan * 42 + 42.0
=> NaN
irb(main):004:0> obj = Object.new and obj.taint
=> #<Object:0xb75a5fac>
irb(main):005:0> (obj.to_s << "string").tainted?
=> true
irb(main):006:0> ("string" << obj.to_s).tainted?
=> true
there's no good reason, imho, why this style of logical behaviour could not be
part of the logical classes (TrueClass/FalseClass) and operators (and, or,
not).
regards.
-a
On Sat, 1 Apr 2006, baumanj@gmail.com wrote:
ara.t.howard@noaa.gov wrote:
On Fri, 31 Mar 2006, Christian Neukirchen wrote:
--
share your knowledge. it's a way to achieve immortality.
- h.h. the 14th dali lama
"baumanj@gmail.com" <baumanj@gmail.com> writes:
ara.t.howard@noaa.gov wrote:
On Fri, 31 Mar 2006, Christian Neukirchen wrote:
> if a.kind_of? Boolean
>
> case y
> when Integer
> when Boolean
> endWhat kind of scenarios would you want to use such a construct? It seems
to me not very rubyish to be switching based on the class of an object.
As I understand it, the more conventional way to deal with potentially
diverse argument types is to use the respond_to? method. This keeps the
door open for duck typing.
Except we don't have a to_bool, either ;-).
Still, I can saw enough cases where I wanted such a "case", and
grumbly used TrueClass,FalseClass.
--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org
} > On Fri, 31 Mar 2006, Christian Neukirchen wrote:
} > > if a.kind_of? Boolean
} > >
} > > case y
} > > when Integer
} > > when Boolean
} > > end
}
} What kind of scenarios would you want to use such a construct? It seems
} to me not very rubyish to be switching based on the class of an object.
} As I understand it, the more conventional way to deal with potentially
} diverse argument types is to use the respond_to? method. This keeps the
} door open for duck typing.
[...]
The most obvious answer is that it is needed for various kinds of
serialization. I wrote something like this just the other day. I needed to
do XML-RPC serialization (yes, I know there is XML-RPC support in the
standard library, but I needed something slightly different that was easier
to do by hand), so I needed to know what kind of value I was serializing.
--Greg
On Sat, Apr 01, 2006 at 12:38:43AM +0900, baumanj@gmail.com wrote:
} ara.t.howard@noaa.gov wrote:
John W. Long wrote:
You could always assign some new constants to them:
True = TrueClass
False = FalseClasscase y
when Integer
when True, False
end
Or just use the literal constants, that already exist:
case y
when Integer
when true, false
end
--
Florian Frank
in a conditional it should evaluate to true/false radomly - compute a random
number and look at the last bit for instance, 0 -> false, 1 -> true.
harp:~ > cat a.rb
def maybe() [rand].pack('f').unpack('c').first[0].zero? end
puts "hello" while maybe
harp:~ > ruby a.rb
hello
harp:~ > ruby a.rb
hello
harp:~ > ruby a.rb
hello
harp:~ > ruby a.rb
hello
cheers.
-a
On Sat, 1 Apr 2006, Niklas Frykholm wrote:
another thing a real Boolean class could give is a 'maybe' obj such that
maybe or true -> maybe
maybe or true and false or true -> maybe
maybe and false -> maybeWhat whould this do
print "hello" if maybe
or this
while maybe
print "hello"
end
--
share your knowledge. it's a way to achieve immortality.
- h.h. the 14th dali lama
Another example where the Ruby 'does the right thing'.
Thanks for the reminder.
Gary Wright
On Mar 31, 2006, at 5:00 PM, Florian Frank wrote:
Or just use the literal constants, that already exist:
case y
when Integer
when true, false
end
What does
[rand].pack('f').unpack('c').first[0]
do that
rand(2)
doesn't?
ara.t.howard@noaa.gov wrote:
def maybe() [rand].pack('f').unpack('c').first[0].zero? end
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
As if my code wasn't already non-deterministic
On Apr 1, 2006, at 10:03 AM, ara.t.howard@noaa.gov wrote:
On Sat, 1 Apr 2006, Niklas Frykholm wrote:
another thing a real Boolean class could give is a 'maybe' obj such that
maybe or true -> maybe
maybe or true and false or true -> maybe
maybe and false -> maybeWhat whould this do
print "hello" if maybe
or this
while maybe
print "hello"
endin a conditional it should evaluate to true/false radomly - compute a random
number and look at the last bit for instance, 0 -> false, 1 -> true.harp:~ > cat a.rb
def maybe() [rand].pack('f').unpack('c').first[0].zero? endputs "hello" while maybe
harp:~ > ruby a.rb
helloharp:~ > ruby a.rb
helloharp:~ > ruby a.rb
helloharp:~ > ruby a.rb
hellocheers.
-a
--
share your knowledge. it's a way to achieve immortality.
- h.h. the 14th dali lama