M
Mark J. Reed
Okay, as a convert from Perl to Ruby, I have to say that I love
just about everything Ruby has to offer. Just about. I wish it had
better built-in support for Unicode, but that's a minor quibble.
However, one thing I really don't like is the handling of booleans.
I would be happy if the conditionals required actual Boolean
(i.e., TrueClass or FalseClass) objects and complained otherwise, even
though it's rather different from the typeless nature of the rest
of Ruby.
I would also be happy if the test for falseness was less simplistic than
"false is false, nil is false, everything else is true". I am constantly
being bitten by the fact that 0 is true.
Ideally, what I'd like to see is the ability for each class to decide what
constitutes true and false for objects of that class - for instance, a
to_b method, by analogy with to_s. Then you just need three method
definitions:
class Object; def to_b() true end end
class FalseClass; def to_b() false end end
class NilClass; def to_b() false end end
And boom, you have the current behavior and the ability to extend it.
For instance, if you prefer that zero be false, you can do
class Numeric; def to_b() self != 0 end end
Admittedly, this would break the semantics of =~ etc, but you could
fix that with a new class for match results that still has 0 as true:
class Index < Fixnum; def to_b() true end end
Similar methods would allow empty strings and collections to return
false, etc. The point is that it would gain a lot of flexibility.
And a static method like this:
def TrueClass.strictlyTrue?(x) x != nil && x != false end
would allow the user to override any given class's definitions to
make sure that an object is "really" true.
Thoughts?
-Mark
just about everything Ruby has to offer. Just about. I wish it had
better built-in support for Unicode, but that's a minor quibble.
However, one thing I really don't like is the handling of booleans.
I would be happy if the conditionals required actual Boolean
(i.e., TrueClass or FalseClass) objects and complained otherwise, even
though it's rather different from the typeless nature of the rest
of Ruby.
I would also be happy if the test for falseness was less simplistic than
"false is false, nil is false, everything else is true". I am constantly
being bitten by the fact that 0 is true.
Ideally, what I'd like to see is the ability for each class to decide what
constitutes true and false for objects of that class - for instance, a
to_b method, by analogy with to_s. Then you just need three method
definitions:
class Object; def to_b() true end end
class FalseClass; def to_b() false end end
class NilClass; def to_b() false end end
And boom, you have the current behavior and the ability to extend it.
For instance, if you prefer that zero be false, you can do
class Numeric; def to_b() self != 0 end end
Admittedly, this would break the semantics of =~ etc, but you could
fix that with a new class for match results that still has 0 as true:
class Index < Fixnum; def to_b() true end end
Similar methods would allow empty strings and collections to return
false, etc. The point is that it would gain a lot of flexibility.
And a static method like this:
def TrueClass.strictlyTrue?(x) x != nil && x != false end
would allow the user to override any given class's definitions to
make sure that an object is "really" true.
Thoughts?
-Mark
+36 20) 356 9656 ICQ: 175564914 poroltoval kellene jarnom" |