> What should we do? The answer to that is actually a simple one, Berin! > > Just make sure that your code only references, and works with, other > java code. Make sure all your 'language extensions', all your magic, > should be able to map to and from (and be replaced by) java code, > directly, intuitively.
<snip/> > what you have here is 'optional' magic. You can remove your attribute > compiler and your attribute metadata by replacing it with pure java > code. When you write unit tests, when you debug your code, when you > deploy to a constrained environment, you replace your fancy stuff with > the pure java. > > I don't feel much like continuously referring to PicoContainer, but this > is a pattern consistently followed there. You normally want to use some > kind of xml declaration of your components (or a script, or an automatic > classpath browser, or ...), but those are *optional*. PicoContainer is > built around being able to replace the xml, the scripts, all that, with > plain and simple java code. I think Leo really has an *excellent* point here. What's really nice with Pico is it's ability to run with or without the magic. They just separated the concern of doing the thing - in plain java - from the concern of making it easy to use the thing - with magic. And it has great implications on the internal design and testability of Pico, as well as on its level of acceptance by the Java Community - what I mean here is that Pico is less frightening thus more accepted. <snip/> Leo, please keep up the good food for the brain ;-) - Vincent --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
