Re: Proposal: runtime-modifying Kernel methods should be keywords

I was going to reply to this In a detailed manner, but I'm not. (I
actually just deleted a lot of writings...) You speak with a certain
vehemence that makes me interpret your words differently from how you
intend them. The reverse is probably true too. We would keep picking
on details, and that gets us nowhere.

I understand your vigor though; JRuby is your brain child, you've
lived and breathed it for quite a while now. I know how it feels. I'm
impressed with what you are doing; what I thought you did has gone
from generating Java source code to actually working right on top of
the JVM and exploiting the HotSpot compiler and all. I actually envy
you a little.

But to get back to the subject at hand... The big question seems to be
what is more important, speed or programmer happiness. Another
question is what is most important in the short term, and what in the
long term. In the end this decision lies with Matz. The way I see it,
in the long term, we can have both, but this requires time and more
people. In the long term, I believe we can even improve programmer
happiness. If we want performance Real Soon Now, then we need to do
something else. I think we both agree on that.

What you could do in the short term is provide a compiler switch that
makes JRuby stricter to allow more optimizations. That should be
pretty easy to do. But rather than making eval and all keywords, you
could simply disallow aliasing them. This is much less restrictive,
and it does solve your problem because the built-in eval can only be
called eval so you can safely detect its presence. This means you'll
have some false positives, but that's OK, and programmers can avoid
this by not using eval as a method name, but then it's the
programmer's choice. Not being able to alias eval feels much less of a
problem to me, especially if you can distinguish between aliasing the
built-in eval and a user-defined eval. It's not ideal, but at least
you can keep on going.

Peter