groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <>
Subject Re: About type inference of method return value
Date Sat, 08 Sep 2018 12:22:25 GMT
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.

> (Using the new var (and existing final without an explicit type) will 
> reduce the cascading type change problem in some cases - whether it 
> leads to more readable code is a different question (although it will 
> still be more readable than having dynamic style def everywhere ;-) )).

lets take the new final for example. Having the ability to not to write 
final will lead people to not to write final by default (unless they 
make everything final anyway, which some do). But this is ok. Not using 
final for cases that are final will then not lead to a problem. Not 
using final for cases where you need final and that are not final, will 
still lead to a compilation error. I don't see a real drawback from the 
optional final.

"var" is a bit a different story. It will lead to surprising types being 
used and partially violates the paradigm that you should not use the 
most special class for your variables if not needed. But even then the 
effect is quite local. If you keep your methods small, as you should 
anyway, then there is not much of a disadvantage here to be seen in my 
opinion. But it already makes the program less readable for another 
user. It is the same in dynamic Groovy with def... Which shows you 
simply have to learn to read the method differently. But the effect is 
very localized.

Now return type inference is not, as I have shown already. And that, 
plus the lazy developer part, is why I am not friend of this.

bye Jochen

View raw message