[ruby-core:77828] Re: [Ruby trunk Feature#12515] Create "Boolean" superclass of TrueClass / FalseClass

The terms "truthy" and "falsey" were used by Douglas Crockford in his 
series of JavaScript lectures at Yahoo about 5 years ago. A value is 
"truthy" if treated as true by a conditional. A value is "falsey" if 
treated as false by a conditional.

Ruby has possibly the simplest, cleanest and easiest to use distinction 
between "truthy" and "falsey" values of any programming language: nil 
and false are falsey, everything else is truthy.

Compare Ruby's to PHP's or JavaScript's allocation of truthy and falsey, 
where empty strings and empty arrays and even zero can be falsey. If 0 
is falsey, should 0.0 be false? What about rounding errors? How about 
complex numbers? expressed in rectangular notation? expressed in polar 
notation? How about multidimensional arrays that contain no values other 
than arrays? How about empty dictionaries? Should they truthy or falsey? 
The richer the language and it's data structures, the more vexing these 
issues become.

Ruby has reduced the confusion to a minimum by keeping the falsey values 
to a minimum: false and nil. Everything else is truthy. And Ruby 
accomplishes this without a Boolean class. Adding a Boolean class to 
Ruby is not necessary, and it would be profoundly inelegant.

I quote the definition of elegance provided by Alex W. White in his 'The 
Elements of Graphic Design': "Distill the essential from the mass of 
confusing muchness. Nothing may be missing and nothing may be 
extraneous. This is the definition of elegance."

There is also a well-know translation of a quotation by the famous 
French pioneer in aviation Antoine de Saint-Exup駻y (as translated by 
Lewis Galanti鑽e): "... perfection is finally attained not when there is 
no longer anything to add, but when there is no longer anything to take 
away ..."

Please don't add a Boolean class to Ruby; it doesn't need a Boolean class.


On 10/30/2016 06:00 PM, [e-mail] wrote:
> Issue #12515 has been updated by Samuel Williams.
>
>
> The fact that so many gems are introducing "class Boolean" is an argument FOR it not AGAINST it, IMHO. Because when this code is loaded together, it might behave strangely if there is no shared meaning for "class Boolean".
>
> Having a Boolean(String) constructor would be useful.
>
> Having a class named Boolean would make things more readable, for example here: http://sequel.jeremyevans.net/rdoc/files/doc/schema_modification_rdoc.html#label-Column+types - you can see that because there is no Boolean class, they resort to, IMHO quite a strange naming convention, using either TrueClass or FalseClass.
>
> The naming of TrueClass and FalseClass are also inconsistent with other names, e.g. it's not IntegerClass or FloatClass or StringClass. It's a little bit ugly.
>
>> There's no meaning for having a superclass of TrueClass and FalseClass as Boolean
> I believe you are wrong on this point. There is meaning.
>
> The meaning is that "This variable is of class Boolean".
>
> There is one example I can think of:
>
> ~~~
> #!/usr/bin/env ruby
>
> x = true
> # x = false
>
> case x
> 	when TrueClass
> 		puts "trueclass"
> 	when FalseClass
> 		puts "falseclass"
> 	# How can we implement this?
> 	# when Boolean
> end
> ~~~
>
> Situations were this kind of logic comes up include serialisation and deserialisation libraries, data modelling, etc.
>
> ----------------------------------------
> Feature #12515: Create "Boolean" superclass of TrueClass / FalseClass
> https://bugs.ruby-lang.org/issues/12515#change-61122
>
> * Author: Loren Segal
> * Status: Rejected
> * Priority: Normal
> * Assignee:
> ----------------------------------------
> Since Ruby 2.4 is unifying Bignum/Fixnum into Integer (https://bugs.ruby-lang.org/issues/12005), it seems reasonable to do something similar for TrueClass / FalseClass, and create a proper Boolean hierarchy. The implementation would be fairly straightforward and should be back compat unless someone already has a "Boolean" class at toplevel out there.
>
> Given the compatibility implications of Integer, this Boolean proposal is even less intrusive.
>
> Sample implementation:
>
> ~~~
> class Boolean < BasicObject; end
> class TrueClass < Boolean; end
> class FalseClass < Boolean; end
> ~~~
>
>
>
>


Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>