From: RRRoy BBBean Date: 2016-10-30T22:49:23-05:00 Subject: [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�ry (as translated by Lewis Galanti�re): "... 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_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: