On Fri, 12 Nov 2004 06:28:51 +0900, Mohammad Khan <mkhan / lextranet.com> wrote:
> On Thu, 2004-11-11 at 16:15, Austin Ziegler wrote:
> > On Fri, 12 Nov 2004 05:41:50 +0900, Mohammad Khan <mkhan / lextranet.com> > > > On Thu, 2004-11-11 at 14:50, Austin Ziegler wrote:
> > No, I didn't. Not anything convincing, at any rate. It seemed to
> > boil down to "I don't think that a == b is sufficiently OO", which
> > is certainly not a good reason, IMO. Why do you not like "a ==
> > true"?
> Personal taste! May be I am fond of wired taste !!
> Sorry for trying to share my wired taste with you.

Perhaps it is a matter of taste -- but is this sufficient reason to
want a change to the language? Again, I differentiate between your
proposal for #true? and #false? and the #iftrue mechanisms, as your
mechanism:

  if a.true?

doesn't really buy anything over

  if a == true

for tests of true-value. Wouldn't it be more OO to actually do:

  a.iftrue { things-to-do-if-true }.iffalse { things-to-do-if-false }

rather than simply what you've suggested?

> > Yes, we do. I don't think, however, that the Ruby world needs #true?
> > and #false?
> well, we need to know first before using something.
> If you are going to use #true?, you need to know what it does.
> I am saying this, for your reply about work with others.
> We really don't have Object#true? in ruby. If you see #true? in my code,
> you got to look around my code to see what it does?
> Same way, If I work with you, you might have some new
> opinion/idea/concept that I am not familiar with. In that case, I will
> have to do the same.

Mmmm. I donno. I don't think that you'd find anyone else using the
#true?/#false? mechanism you said. Most other folks would use
unfamiliar ideas, not unfamiliar and unintuitive syntax. To me, it is
*not* immediately obvious that #true? and #false? would test against
== true and == false.

-austin
-- 
Austin Ziegler * halostatue / gmail.com
               * Alternate: austin / halostatue.ca