From: matthew@... Date: 2016-11-04T22:42:12+00:00 Subject: [ruby-core:77939] [Ruby trunk Feature#12515] Create "Boolean" superclass of TrueClass / FalseClass Issue #12515 has been updated by Matthew Kerwin. Samuel Williams wrote: > > Finally, if this really is the issue, then either 1/ put it inside `require 'boolean'` or 2/ release with ruby 3.0 - there are plenty of options, one does not need to be so pessimistic. > It's just one of the issues, but it's the one backed by the same numbers you seem to think are the be-all and end-all. Anyone can munge code to not conflict with existing implementations. (`Kernel::Boolean`? Really?) > > Personally, I find Matz argument about duck typing superficial. Because, this isn't a case of duck typing (abstraction) but set membership (is this either true or false). We already have useful checks for these things for Integer, Float, Numeric, String, etc. Why not Boolean? It's inconsistent. > It's because, as has already been stated, Integer#+ and Float#ceil are methods with implementations shared by all instances of those classes. There is no such method to define on Boolean. And if it's all about set membership, why is `NIL` not an instance of Boolean? (It is false) Why not all other objects? (They are true) You are free to define whatever arbitrary sets you like, in whatever context it's appropriate. Put `"Y"` in the truthy set and `"N"` in the falsey, I don't care. But that doesn't mean you should push those (or any) arbitrary set memberships into the core. ---------------------------------------- Feature #12515: Create "Boolean" superclass of TrueClass / FalseClass https://bugs.ruby-lang.org/issues/12515#change-61260 * 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: