[ruby-core:21212] Re: Definable != is a Bad Thing???

On Wed, Jan 7, 2009 at 21:49, J=F6rg Mittag <[e-mail]> w=
rote:
> Kornelius Kalnbach wrote:
>> Daniel Luz wrote:
>>> What I personally don't like about this is that it gives you a false
>>> sense of control. We still can't handle && and ||
>> the problem is short-circuit evaluation, I guess. this one should not
>> run the command:
>>
>>   false && `rm -rf .`
>>
>> it has to be part of the AST, and can't be changed at runtime. AFAIK,
>> you can't translate "a && b" into a method call in Ruby. they are more
>> like "and" and "or". the ternary operator (cond ? truecase : falsecase)
>> is another example - which is a shortcut for if-then-else. and you don't
>> want to redefine that ^^
>
> I was bored, so I went ahead and implemented it:
> <https://JoergWMittag.GitHub.Com/b001e/>.
>
> There is actually absolutely nothing original or hard about this

We're going way off the original topic, but actually, there is: make
it as efficient as what we have today :)

I'm well aware you can simulate a lot of this behavior with what the
language has today, but it's like removing conditional, loop and
declaration syntax in favor of using exclusively method calls with
blocks: possible as a fun experiment, not really feasible with the
current language semantics and implementations, unless you don't care
about performance.

I know Ruby is not about raw speed, but still, there are various kinds
of sacrifices of "freedom" that are quite small compared to the speed
and memory gains we can get. I personally don't care losing the
ability to redefine the language's boolean logic, if that means very
efficient bytecode (and very straightforward conversion to native code
in this regard).

Then again, my point a couple messages ago was that unless we go this
way and give more freedom on the boolean operators, being able to
redefine "!" alone would be a pretty leaky abstraction. I really like
the cleverness of stuff like Ambition[1], but I personally prefer the
analysis of blocks (via AST, bytecode or whatever) over faking through
method_missing hacks and failing the moment you introduce an "&&" on
your expression.

[1] http://defunkt.github.com/ambition/

--
Daniel