On Mar 7, 2020, at 2:22 PM, fo...@univ-mlv.fr wrote: > > Marker interface are usually problematic because: > - they can inherited, for inline classes, you can put them on our new kind of > abstract class, which will make things just harder to diagnose.
As always the flexibility of inheritance cuts both ways. Suppose I define AbstractSlice with subtypes MemorySlice, ArraySlice, etc. and I intend it for secure applications. I then mark AbstractSlice as NonTearable, and all its subs are therefore also NonTearable. You cannot do that with an ad hoc keyword, even if you want to. You have to make sure that every concrete subtype mentions the keyword. It’s a trade-off, of course, but for me the cost of a new keyword pushes me towards using types making the property inherited. It’s a decision which falls squarely in the center of the language. > - they can be uses as a type, like Serializable is used where it should not. > By example, what an array of java.lang.NonTearable means exactly. There is a > potential for a lot of confusion. Again, if I have an algorithm that works for a range of value types (via an interface or abstract super), I can express the requirement that the inputs to the algorithm be non-tearable, using subtypes. For example, the bound (Record & NonTearable) expresses and enforces the intention that the algorithm will operate on non-tearable record values. > and in the specific case of NonTerable, a non inline class can implement it, > again creating confusion. The confusion comes from the incomplete story here. I’d like to suggest that IdentityObject implements NonTearable, so that bounds like Record & NonTearable allow identity and inline objects. — John
