PROPOSAL: 'final' without explicit type (update)
reinier at zwitserloot.com
Tue Mar 31 08:28:12 PDT 2009
This isn't the first time I've read about inferring types, and this
isn't the first time I've seen 'final' used for it.
It's -not- just to avoid a new keyword. It's quite specifically
because auto-typing should only be done for final variables. The
problem is this:
List<String> list = new ArrayList<String>();
The LHS type is not the same as the RHS type. Virtually all java
programmers would agree the above is superior to:
ArrayList<String> list = new ArrayList<String>();
for two reasons:
1. You will not be able to assign another type of list to this thing
2. You will not be calling arraylist-specific methods (which there
are none, but let's argue for a moment that there are), eventhough the
intent is for 'list' to perhaps hold some other non-ArrayList list, and
And yet, with type inference, you'll get ArrayList<String> on the LHS,
and not List<String>.
Both of those reasons become moot, or almost moot, if the variable is
1. It's final. You can't assign anything to it, so no problem here,
2. Because you can't assign anything else, calling arraylist-
specific stuff is less of an issue. The issue doesn't go away entirely
(and this is in fact the only reasonable complaint against the final-
without-explicit-type proposal that I can think of) but it becomes
much less important. It is further mediated by the idea that java
allows you to operate on expressions and not just variables, and
expression do quite auto-infer (and are in essence final, you can't re-
assign the value of an expression, of course!), so there's precedent,
which is always a good thing for language changes.
In other words:
is perfectly legal, and yet it has the exact same problem that,
supposedly, a (final!) implicit variable type would have: If you were
intending to change that linkedlist for an arraylist later, than
'push' was not a method you were supposed to call on it.
As the above example clearly shows: It's a problem, but not exactly a
backbreaking one. We've been dealing with it for years.
FWIW, I'm -strongly- in favour of implicit typing for final local
method variables, and opposed to extending this for non-finals, not
just because its hard to come up with a syntax for it, due to there
being no readily available keywords or operators to do it with. :=
comes to mind, but that's about it.
NB2: If you want to push forward with this proposal anyway, I strongly
suggest you rewrite it to this, which would be far more backwards
foo := expression;
auto foo = expression;
On Mar 31, 2009, at 15:43, Tim Lebedkov wrote:
> 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?
> 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
>>> 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
>> 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)
>> 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