I believe this to be incorrect. (1) and (3) are quite distinguishable. In the case of (1), an author would most likely use either a
trait or an
abstract class, where’s in the case of (3) an author would not.
The way I see it, when authors intend for users to extend a class (1), they doucment it – either in code comments (scaldoc) or in an online resource (README, site, etc). Annotation are also a way to imply intention (assuming they are documented).
This is the crux of the problem with this SIP. It will change the way developers interact with third party libraries. I believe that in most cases, (3) is the state of affairs, which is actually a good thing, as authors cannot accurately predict the way their library will be used, and they often can rely on users to explore new ways of interacting with their library.
This is also why I’m against having a warning when users extend “simple” classes. In my opinion, this is not actually a risk, but a common use-case. I mean, using a third-party library is always a risk in itself, should we warn on that?
If you are using a third-party library in any way then you are tightly coupled with it by definition, and you have no real control over its development, which may break in the future. This is the nature of development and out-sourcing your work someplace else.
Perhaps the only thing Scala should introduce is a new annotation which indicates that a class / trait is intended to be extended.
open should be