(Ok, point taken, and no I don't know why. Because it wouldn't be
that clean otherwise?)
Ā·Ā·Ā·
On Sun, Oct 27, 2002 at 06:28:04PM +0900, Giuseppe Bilotta wrote:
> > 1. Why couldn't one swap 'true' and 'false' in your square-bracket
> > comments in the above?
>
> You mean like in Unix, where 0 means success and non-zero means failure?
This is true under DOS as well (errorlevel 0 => success), but just
because non-zero means "there was an error", so it *is* true, and
zero is false (no error).
Of course if you're an optimist and look at it from the "success"
viewpoint ...
But the shell 'operators' treat 0 as true and 1 as false, if you use the
traditional definitions of 'and' and 'or':
On Sun, Oct 27, 2002 at 10:07:31AM +0900, Phil Tomson wrote:
[snip explanationā¦ still donāt see how it implies ordering, sorry :-(]
Anyway, I guess Iām in the camp that would like to see some kind of
hierarchy like:
class Boolean
ā¦
end
class TrueClass < Boolean
ā¦
end
class FalseClass < Boolean
ā¦
end
Then there would be some kind of type relationship between TrueClass and
FalseClass. That would just seem to make more sense to me, but I do see
the potential pitfalls with that approach too.
Iām wondering what happens when subclassing Boolean a third time.
What would the relationship be among this third class and FalseClass
and TrueClass? And what relationship among its instance (or rather
its singleton) and true' and falseā?
Does a class model actually make sense here?
Sure, there are problems with that approach. Itās not perfect.
Iām pretty sure that the way true and false are currently handled will not
be changed anytime soon.
Yes, and no. From the perspective of set ordering, absolutely. From
the problem of allowing two and only two subclasses from an abstract
class (which is what should be allowed), no. Perhaps the appropriate
solution might be to still have two independent singleton classes
(TrueClass, FalseClass), but also have a helper class Boolean that
programmatically defines the Boolean relationship as a āsetā (an
Array, in this case:
class Boolean
import Singleton
@@order = [false, true]
end
Maybe. The class would have to be frozen and somehow not
subclassable, but that seems like it would allow the sometimes but
rarely necessary ordering/comparison between true and false values.
-austin
ā Austin Ziegler, austin@halostatue.ca on 2002.10.28 at 00.18.31
Ā·Ā·Ā·
On Mon, 28 Oct 2002 06:56:51 +0900, Massimiliano Mirra wrote:
On Sun, Oct 27, 2002 at 10:07:31AM +0900, Phil Tomson wrote:
Anyway, I guess Iām in the camp that would like to see some kind
of hierarchy like:
class Boolean; end
class TrueClass <Boolean; end
class FalseClass <Boolean; end
Then there would be some kind of type relationship between
TrueClass and FalseClass. That would just seem to make more sense
to me, but I do see the potential pitfalls with that approach
too.
Iām wondering what happens when subclassing Boolean a third time.
What would the relationship be among this third class and
FalseClass and TrueClass? And what relationship among its instance
(or rather its singleton) and true' and falseā?
I think this is only because of practicality reason. Unix was written in
C, and because C cannot return multiple values in a function and there is
no built-in type of type āstringā, the ācheapestā way of returning
something from a function is by returning an int.
In Unix, it is tradition that when everything works well, Unix is quiet,
and when there is some error, Unix tells the user. So if success is 1 and
failure is 0, Unix cannot easily report the nature of error. But if it is
reversed, when 0 is success and non-zero is a failure, they have so many
integers that can be used to specify the the type of error. But well,
then they had to reverse the boolean values in the shell to mean that 0 is
ātrueā (actually āsuccessā) and nonzero as āfalseā (actually āfailureā).
