Issue #12515 has been updated by Matthew Kerwin.


Samuel Williams wrote:
> > But that's how things already are, and the market deals with it just fine. 
> 
> Well, I know you are being metaphorical ("market deals with it"). But this is not really a case of a market, and I prefer DRY for many reasons. There should be one correct implementation and it makes sense for it to be within Ruby.
> 

It's not a metaphor, it's the real world. Ruby gems exist in open competition, and developers have the opportunity to choose between (or create alternatives to) any available gems in the ecosystem.

If there should be one "correct" implementation, why do we have gems at all? *Everything* should be in the core. And that's without even starting the big argument about which approach should be considered "correct." (Anyone who says `"N"` is falsy-y in all cases is going to have some serious arguing ahead of them.)

> 
> To be explicit about it: If I include two gems, and they both define "class Boolean", and they collide for some reason, it's a problem for me, and it might not even be an obvious problem.
> 

Indeed. That goes back to an open marketplace and market forces. You say, "If I do this..." but I say, "People already live with that possibility and seem to be surviving just fine."

> 
> > What "something" would you do that is identical for both True and False?
> 
> Sometimes you need to handle multiple data types this way because the functionality is on core classes that you don't want to extend. It's similar to how type classes work in Haskell.
> 
> *[snip]*
> 

Everything you've listed there is a *type*. Ruby doesn't do types like that. You're conflating the class hierarchy with types.

> 
> Unfortunately in Ruby, the type constructors (`Kernel.Integer`) are free functions, not part of the class, e.g you can't write `Integer.parse(input)`. You need to write (verbosely on purpose) `Kernel.Integer(input)`. It's not very OO.
> 

They're not constructors; Integers (well, Fixnums) are singleton and cannot be instantiated. The methods you're talking about are for coercion. (And very specific coercion at that.)

If you want to talk about OO, the casting methods (e.g. #to_i) are defined on the object-to-be-recast, or an intermediate expert. The destination class doesn't *and shouldn't* have responsibility to understand every possible class or type of object, and know how to convert them all to an instance of itself. There are all sorts of anti-patterns in there. (Said another way: a String should know whether it represents a 'true' or 'false' value, or there should be an object that knows just enough about Strings and booleans to be able to manage the conversion.)

> 
> Another case would be handling the above, e.g. `Boolean.parse(input)` or `Kernel.Boolean(input)`. It would make sense if they could turn the string representations into boolean values and throw an `ArgumentError` if not convertable.

I posit that it should be something like `String#to_bool`, since the String is the thing that knows whether and how it represents a boolean value.

There is no value is defining a `Boolean` superclass of both `True` and `False`.

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

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