final abstract class

["Zdeněk Troníček"]

Brian Goetz napsal(a):
> What you're working against is the "human factors" that is implicit in
> the naming chosen in 1996.  Abstract (in the context of a class) may
> mean "non-instantiable", but it also means "may have abstract methods",
> and the user's mental model of what abstract-ness means is closer to "I
> have to supply some method implementations" than "non-instantiable".
> With this meaning of abstract in mind, "abstract final" kind of sounds
> like an oxymoron.

I have doubts that "I have to supply some method implementations"
dominates over "non-instantiable".
Let's have a look at
http://docs.oracle.com/javase/tutorial/java/IandI/abstract.html:

"An abstract class is a class that is declared abstract—it may or may not
include abstract methods. Abstract classes cannot be instantiated, but
they can be subclassed."

And Wikipedia
(http://en.wikipedia.org/wiki/Class_%28computer_programming%29#Abstract):

"In a language that supports inheritance, an abstract class, or abstract
base class (ABC), is a class that cannot be instantiated because it is
either labeled as abstract or it simply specifies abstract methods (or
virtual methods)."

> When looking at a proposed language change, it is natural to focus on
> "if we had this feature, I could write this-and-such code, which is
> good."  Unfortunately, this is mostly looking in the wrong direction.
> You need to be looking at interactions with other features, what BAD
> code a feature might also enable, and how it affects the "shape" of the
> "language boundary" (more complex boundaries are harder to understand
> and more error-prone.)

Right (especially I agree with "if we had this feature, I could write
this-and-such code" - this is wrong direction). But it is not appropriate
here.
1) "final abstract" means that the language will not need one exception
from syntax rules (this exception is "final and abstract are not allowed
together". Such exceptions are usually considered bad.
2) The modifiers appear in javadoc which means that it improves the
documentation.

What interactions with other language features do you mean? And what bad
code are you writing about?
The change seems to be fully backward compatible.

> The downside of a feature like this is the damage it does to the user's
> simplified mental model of what "abstract" means.  (Not to say I don't
> like the motivation -- I find having to write a private ctor to be an
> inelegant hack too.)
>
>
> On 8/12/2012 1:08 AM, "Zdeněk Troníček" wrote:
>> Hi,
>>
>> we cannot subclass a final class and cannot instantiate an abstract
>> class.
>> Why a combination of final and abstract is not allowed? Declaring a
>> class
>> final and abstract would express in elegant way what is now done by
>> final
>> and private constructor.
>> (Certainly not a big thing but the required changes in javac does not
>> seem
>> to be large either.)
>>
>> Z.
>>
>