concrete abstract classes

[kjx]

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

 myClass(x)  

would be outlawed in such a class

 object {
    inherit myClass(x)  
  }

would be fine. Java has the same problem there

[KimBruce]

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.

[apblack]

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.

[kjx]

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)...?