Open kjx opened 8 years ago
It's an interesting issue. I can see circumstances in which I would like to make a class abstract even though all the methods are concrete (e.g., I design a class only to be used via inheritance). However, my students get very confused by it. It makes me wonder whether it is worthwhile adding a new construct just to make abstract/concrete classes definable.
This happens rarely. Most of the time, such as class will actually be a trait, and then it can be declared using the trait keyword, which is a clear message that it's intended to house shared behavior, rather than for instantiation.
Occasionally, it can't be a trait, because there is state in it. Then, the intent can be made clear with the class comment.
// This class is intended to be used to provide uuids to its sub-classes.
// While it can be instantiated directly, it doesn't by itself model any interesting
// application-domain artifact.
I don't now see a need for any new language syntax or even an annotation. If this turns out to be important, an annotation can always added later.
I guess an "is abstract" annotation (or something) on a method? (or object constructor) could throw an error if they were invoked NOT from an inherits or use clause (i.e. without a creatio)...?
So we have "required" aka "abstract" for methods.
how do we have abstract classes? --- in particular, concrete abstract classes, classes where every method is defined but where we don't expect direct instances.
of course perhaps it's not worth bothering --- even if
would be outlawed in such a class
would be fine. Java has the same problem there