On Feb 19, 2008 9:35 AM, Guillaume Laforge <glaf...@gmail.com> wrote:

But it's easier _not_ to use Java, and breaking out pieces for performance reasons can quickly lead to bad encapsulation and OO design.

Of course not just as fast, but "close enough" for the sake of such a convenience.

Maybe _my_ codebase. But then that's what annotations are for. I don't consider it litter; it's metadata, used judiciously where necessary. And the current solution of "break out into Java where needed means my codebase from a file perspective is littered with Java files, so I have to keep switching to other files to see a complete picture of what is going on.

I wouldn't ask such annotations to be put in the core Groovy libs. But let _me_ use them if I want to. Obviously @Property wasn't necessary because a sensible convention could be used instead. I don't think this is comparable and wouldn't be used nearly as often.

Nobody is asking you not to make "dynamic Groovy" faster. The two aren't exclusive and nobody is saying "just do this and ignore the real issue." If it were a matter of manpower and this would take too much effort then fine, you have to concentrate on the long term. But it sounds like there are other people who want to do this.

I would say this is a valid point _if_ dynamic code could become as fast as the statically annotated equivalent. Because then the annotation would be obsolete. But I think even given all of the bytecode generation and callsite caching enhancements that have been discussed, this annotation would still give better performance, no?