groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <>
Subject Re: About type inference of method return value
Date Sat, 08 Sep 2018 17:36:03 GMT

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.


*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 ;-)

View raw message