Re: Groovy performance: what to do

> [...]
>  2/ As we have previously discussed, I also like the idea of letting
>  the developer decide on which parts he/she wants strict/dynamic
>  typing. And if this is the only option to get a huge performance
>  improvement for the 1.5 branch then I guess it may be worth to offer
>  this option to our users.
>
>  Concluding, for me the near future of Groovy depends a lot of the
>  language consistency and performance (and in a smaller measure to its
>  API stability -- remember I've said near future). I would like to have
>  a new version whose overall performance is improved thanks to
>  clarifying the details of the MOP/Categories implementation. And I do
>  believe that thanks to the consistency introduced by such a
>  reimplementation most of the people will be willing to switch to the
>  new version. However, for those that have invested a lot in the
>  current version, the solution you're suggesting may work (and I do
>  think it may be useful also in the next version).