Re: annotations or traits to better scale scala up

Walter Smith wrote:

DontAssign: Like HashMap example above, this type is not meant for variables, values, or return types. Just use it for construction.

I see two sides to this. The first is in issuing warnings should somebody use the class manually, for example:

   val map: HashMap
               ^ Cannot use scala.collection.mutable.HashMap as a value type, suggest scala.collection.mutable.Map instead

This could get *really* annoying if used incorrectly. For example, if HashMap implemented a method that Map does not.

Walter Smith wrote:

DontExtend: This class is meant to just be called by client code; avoid the much stronger coupling by implementing a trait or extending a class. This privilege is left to the library itself.

Can't this be achieved with the sealed modifier? That prevents the class being extended except in the same source file.

Walter Smith wrote:

DontSerialize: Stronger than the above... the library is holding references that would get lost (e.g. Hibernate). Libraries serializing objects would have to somehow specify that they don't like such types. There generally should be a way to decouple such objects.

If you extend Externalizable and throw an exception on the methods, that would prevent it from being stored at runtime. But presumably a compile-time check is preferable.

Walter Smith wrote:

Immutable: The class guarantees that it recursively has no variables and is purely functional. (I think this is a must!)

In most cases, this could be derived by the compiler rather than needing to be specified manually.

What would you do with this metadata? How would it be treated differently?

Walter Smith wrote:

Key: Instances of this class can be used e.g. as a key in a HashMap, i.e. the class overloads == and hashCode.

Are you suggesting that a HashMap would refuse to accept any non-valid keys? This could be accomplished with a trait applied by the compiler, but any class that wasn't compiled with this trait would then be invalid - including String. You could define a conversion to RichString - including a translation of HashMap[String, _] to HashMap[RichString, _], but this could cause unexpected problems.