PROPOSAL: 'final' without explicit type (update)
tim.lebedkov at googlemail.com
Tue Mar 31 06:43:21 PDT 2009
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
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ł:
>> 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
> "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ł
More information about the coin-dev