PROPOSAL: 'final' without explicit type (update)

[Tim Lebedkov]

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/
>
>