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=E9ry (as translated by =

Lewis Galanti=E8re): "... 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, samuel / oriontransfer.org 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_rdo=
c.html#label-Column+types - you can see that because there is no Boolean cl=
ass, they resort to, IMHO quite a strange naming convention, using either T=
rueClass or FalseClass.
>
> The naming of TrueClass and FalseClass are also inconsistent with other n=
ames, e.g. it's not IntegerClass or FloatClass or StringClass. It's a littl=
e bit ugly.
>
>> There's no meaning for having a superclass of TrueClass and FalseClass a=
s 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 =3D true
> # x =3D 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 des=
erialisation 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 Tru=
eClass / FalseClass, and create a proper Boolean hierarchy. The implementat=
ion would be fairly straightforward and should be back compat unless someon=
e 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:ruby-core-request / ruby-lang.org?subject=3Dunsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>