"Brian Mitchell" <binary42 / gmail.com> schrieb im Newsbeitrag 
news:fcfe417004103112046c26579e / mail.gmail.com...

>> Using instance variable @condition is likely to break in multithreaded
>> applications.  Also, I don't understand why you use a continuation here.
>> Why is that?
>
> I am simple avoiding using method chaining. Note that I put this
> together in a few minutes also ;) .

That's funny: I'd *never* cook something up in a few minutes with 
continuations. :-)  Nice to see how everybody has different things they try 
to avoid.

>> I'd say you use polymorphism instead of duck typing because you rely on
>> different behavior of certain methods.  At least that's the important
>> mechanism in this context IMHO.
>
> I say duck typing out of slight mistake (you are right there). I made
> this word choice because that is how boolean *type* can be deduced.
> Not Ruby *type*. Its just a matter of how you look at things.

As often.

>> I'm not sure whether I like the idea to be able to mess with such a
>> fundamental thing as boolean values.  Currently I can't see what we would
>> gain.  OTOH, Ruby allows us to modify a lot internal behavior.
>
> Its for peace of mind.

Well, *your* peace of mind.  Others might get restless and... :-)

> Actually, its for control of more things and
> making more things fundamental rather than just-another-feature. If
> you examined Ruby as a set of axioms which the language was built off
> of before and after this you would notice that the base mechanics of
> the language have become simpler while retaining most (or more?)
> capability. It may also have further ramifications in future things we
> may want to change but needed something like this to get to that
> change to work well. (If that made any sense)? I see that as we work
> on this project pros and cons will become more apparent.

Yeah, probably.  I'm open to convincing arguments / proofs of concept.

>> Could even be a showstopper...
>
> Yes, but part of the idea is, IF we can present this as a positive
> change even in the face of incompatibilities then it would be worthy
> of an RCR.

Definitely.

> Ruby 2.0 will change a lot. The question is, "Is it worth
> the break in functionality or do we even need the functionality?"

Exactly.

> I am currently tyring to think of ways to get it to work w/o drawbacks
> of 2.0 block semantics.

I never remember the exact changes although I do remember that there *will* 
be changes.  The discussion was just a tad too lengthy for my small brain. 
:-)

> I appreciate the feed back. Thanks and I will work on this either way.
> It is a good educational experience.

I'm glad I could help and you didn't feel offended.  Whatever the outcome, 
you - and probably we all - will have gained new insights and learned 
something.

This one just stroke me: if syntax could be further relaxed without 
introducing ambiguities then maybe we'd be able to write something like this 
without other means:

expr.ifDo { puts "true" } :elseDo { puts "nah" }

Relaxations we'd need for this

 (i) make argument separators (",") optional

 (ii) make "lambda" optional when curly braces contain code (as opposed to 
"x=>y" hash declarations.

Equiv. current syntax:
expr.ifDo lambda { puts "true" }, :elseDo, lambda { puts "nah" }

Alternatively

 (i') make method invocation dot (".") optional

 (ii) (as above)

expr.ifDo { puts "true" } elseDo { puts "nah" }

Equivalent of current impl would be

expr.ifDo { puts "true" }.elseDo { puts "nah" }

I don't have enough insight at the moment to judge whether those relaxations 
possible at all but I guess there'll be too many ambiguities...

Kind regards

    robert