Issue #12515 has been updated by Matthew Kerwin.


Samuel Williams wrote:
> 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".
>

But that's how things already are, and the market deals with it just fine. Adding a core 'Boolean' class means every existing implementation, even those only ever used in isolation, will suddenly have a conflict.

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

If that was:

~~~ruby
case x
when Boolean
  #do something
end
~~~

What "something" would you do that is identical for both `True` and `False`? Or put another way, what method would you define inside `class Boolean` that is useful to both `True` and `False`? This comes back to one of Ruby's basic OO-tenets: that classes have shared *functionality*, not a shared *type*.

----------------------------------------
Feature #12515: Create "Boolean" superclass of TrueClass / FalseClass
https://bugs.ruby-lang.org/issues/12515#change-61123

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