--------------enigAFF9775C3BE838B1B746E980
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Max Muermann wrote:
> I can only speak from a Java perspective here, but if you look at what
> most frameworks and (shudder) containers out there do, you'll find
> there is an enormous amount of reflection going on. The more modern
> frameworks also make use of runtime bytecode manipulation. 

Though to me it seems like runtime bytecode manipulation is still rather
rare, I see load-time enhancement much more often. While still magical,
changes made in the scope of a given class don't directly propagate into
other classes. If you can mention a counterexample though, do so so I
know what to avoid.

> Both of
> these techniques introduce the same type of dynamics into a project
> (and negate the "advantages" of static typing)

This is not completely analogous. Reflective method calls still fail
early on type errors. I would prefer if path expressions and their host
documents were precompiled if possible instead of handled reflectively
though. JSP + JSTL + EL must be the single worst combination of
technologies to debug and generally maintain.

> , but - unlike Ruby - it
> is almost impossible to understand what is going on under the hood.

Depends on the definition of "understand". If you mean trace the
(possible) inner workings in your head, then you're right; however,
usually just knowing the actions and corresponding results is enough to
use the code. Which is another reason why learning programming languages
is a valuable hobby - if you've seen a mechanism in one language (and
understood it because that allowed for a clear executable notation), you
don't have much problems using effectively the same thing in another,
even if the implementation jumps through hoops. You just don't need to
care as long as it works.

> And every framework does things in a different way. At least with
> Ruby, you can recognise this kind of metaprogramming easily, and if
> used in libraries its use is normally well documented.
> 

In Ruby, metaprogramming alterations aren't nearly perfectly consistent
between libraries, only the low-level implementation methods which you
usually don't need to care about are the common denominator. Valuable as
a learning resourse, I maintain that it's not quite relevant in practice.As for recognition, I don't think it's too language-specific once you're
familiar with the high-level concept being realised; same for the
documentation.

> Ruby programmers are simply more aware of these features and are
> therefore able to use them effectively.
> 

This is a double-edged sword. Java runs less risk of the features being
used maliciously because of the programmers being unaware. I'm not
stating this is a linearly better state of affairs, it just happens to
result in Java metaprogramming being contained to a select few
frameworks, where it's less likely destructive conflicts will occur.
It's still possible, and might yet show up as an issue, just not in the
near future.

However, greater skill in metaprogramming does NOT follow from greater
awareness. You can be able to recite five ways of dynamically definining
a method from heart, and still mess up someone's number-munging script
because you absolutely had to require mathn instead of just using the
other operators.

David Vallner


--------------enigAFF9775C3BE838B1B746E980
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)

iD8DBQFFdMsky6MhrS8astoRAmrhAJ9Q7hpLPKPczcNXihaE2O7BS74iSwCeOIZX
aPWxIZVQ1l4FWkhNZhHXDicßÛt
-----END PGP SIGNATURE-----

--------------enigAFF9775C3BE838B1B746E980--