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
~~~




-- 
https://bugs.ruby-lang.org/

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