PROPOSAL: 'final' without explicit type (update) (original) (raw)

Tim Lebedkov tim.lebedkov at googlemail.com
Tue Mar 31 06:43:21 PDT 2009

Hello Marek,

my proposal (http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001055.html) is very similar to yours (it just uses 'auto' instead of 'final').

Does yours declare variables as final (I mean here 'constant') only because you try to avoid introducing a new keyword? Or is there another motivation?

Tim

On Tue, Mar 31, 2009 at 8:40 AM, Marek Kozieł <develop4lasu at gmail.com> wrote:

W dniu 31 marca 2009 03:06 użytkownik Gabriel Belingueres <belingueres at gmail.com> napisał:

Why? final a = 1; // static type is int final b = new Integer(6); // static type is Integer If this is confusing for someone: final c = 1 + new Integer(7); then declare it as usual. I just think that in this form solution will be easier to use. Assuming that getLocalization() returns a Localization, then the whole point is that you don't need the cast; otherwise this feature is of doubtful utility. The variable type is known at compile type to be a Localization. "o is Object" for any reason, if it would be Localization then problem would not exists. OTOH, if the getLocalization() returns an Object, then final o = (Localization) some.getBoo().getLocalization(); might throw a ClassCastException at runtime, which is a pity because this is a new feature. If you want to risk to receive a ClassCastException, then declare it as usual: final Localization o =  (Localization) some.getBoo().getLocalization(); What for if we already casted it ?

IMHO, type casts should be forbidden, or at least discouraged. I can agree a little. -- Pozdrowionka. / Regards. Lasu aka Marek Kozieł http://lasu2string.blogspot.com/

More information about the coin-dev mailing list