On 08.09.2018 14:22, Jochen Theodorou wrote:
On 07.09.2018 19:24, mg wrote:
[...]
The general, changing-return-type-only case for me falls under the
responsibility of the developer: He will have to decide whether using
type inference is the right choice here, and fix any potential future
errors that might occur if the inferred type changes. If you use
inference everywhere, you should not be surprised if a change in one
place leads to a domino cascade of type errors in other places - and
you should ask yourself, if you should not go def / duck typing (ie
dynamic Groovy) all the way, if you dislike giving types explicitely
so much... (which in practice will often mean that your IDE will do
the type inference for you ;-) ).
why should we add a change, that will shorten programs and falls
perfectly in to the lazy developer realm, just to advice not to use
it? This is different from adding a special feature, for which you
have to do special things. I expect this to be used by default by many
people.
Because, as you pointed out, using it everywhere leads to a pletora of
problems in practice, and therefore is not lazy, but dumb*.
It is a feature that has its uses in simple, boilerplate code cases,
such as in the example I have given:
class PERSON_ORGTREE_Table {
// Default table instance
@Lazy static final it = new PERSON_ORGTREE_Table("PE_OT", ...)
// Specifically named, statically importable getter for it-instance
static PERSON_ORGTREE_Table getPERSON_ORGTREE() { it } // Current
Groovy: PERSON_ORGTREE_Table return type has to be given explicitly
static getPERSON_ORGTREE() { it } // Future Groovy: No explicit
return type necessary
}
Here it would be helpful and harmless, and therefore Groovy to me. It's
as simple as that.
Cheers,
mg
*I'd much rather be a smart programmer, not a lazy one, even if I have
never heard the term used together with "realm" before ;-)
