Increasingly, I find that in Java programming, I really actually only use a subset of the actual language. For example, I find that whenever I write a class in Java, I make a decision at design time about whether this class is going to be what I call a value class, or an entity class.

A value class is something like java.lang.String, or java.util.Date, and has the following characteristics:

• it is not designed to be extensible: you never intend for someone to subclass it. Therefore, it is always written as a final class. e.g.

    public final class SortCode {
        // blah blah blah
    }

• You always wish to define an equals() method, and declare a hashCode() function.
• You never care about identity - generally it's a mistake if you care whether or not you are referring to the same instance of a java.util.Date or java.lang.String class.
• Because Java makes copying an awkward and somewhat expensive operation, it usually makes sense to make the actual class instance immutable. That is, it has no setter methods on it, and its private data members are also declared final. Making the class immutable makes it easier to use as a key in a map, as well as making it safe to share between threads.
• A value type should only contain references to other value types, or raw primitive types - otherwise it would effectively become mutable.
• If you were to send a value type over the wire, you would serialize its state explicitly.

Some of the above concepts go together. For example, if you made the value class mutable, then it would start making sense to talk about identity again - but while a class is immutable, identity is something you would only use perhaps as an optimization for your equals method. Serializing and de-serializing a value type is relatively simple again because you do not care about identity.

An entity class has many of the opposite characteristics:

• it is specifically designed to be subclass-able. In fact, it is arguable that all entity classes should be defined at least initially at design time as interfaces.
• You never really want to declare an equals() method for an entity class - however, identity is a meaningful concept for entity classes. It is often useful to know if you are dealing with the same entity as before.
• entity classes can be mutable
• entity classes can refer to other entity classes as well as value classes.
• If you were to send an entity class over the wire, you would send a "proxy" to that class over the wire.

So for example, a "Cat" class would definitely be an entity class - you would never declare an equals() method for a Cat class because it's really not intuitively clear what it means to say that one Cat is "equal" to another cat. However, it does make sense to say that you are referring to the same Cat as before. On the other side, a "Colour" class would definitely be a value class. You might say that two cats have the same colour if their two Colour objects were both "Red"...

Well, many of these concepts have been discussed before - but what I wonder is, what if we had some new language that clearly specified this as a language concept. For example, instead of writing:

public final class Date {
    /// blah blah
}

You would write

public valuetype Date {
    /// blah blah
}

The use of the "valuetype" keyword would imply "final class" - but would also force you to declare an equals method and hashCode() function, and would not allow you to compare identity.

In return for making these "restrictions" on the programmer (although many would argue that such "restrictions" would actually make for clearer and more maintainable code) the language could make certain optimizations that are not available to languages such as Java. For example, if your new language imposes that value types should stay immutable, you immediately remove any possibility of circular references. This in turn would mean that you could use simple and efficient reference-counting for managing your value types, instead of other more complicated garbage collection schemes whose performance is harder to guarantee. If you additionally removed the ability to compare identity of value types, your compiler could decide to pass "small" value types (doubles, ints, floats) by value and save any heap allocation altogether.

Of course, a new such language would have more features than just these - and possibly I haven't quite nailed down exactly which concepts are the "useful" ones to giving good performance - this is just a start!!!! :-)

Thinking over this some more, my "value type" has a lot of similarities to C#'s new interpretation of the "struct" keyword... but I've probably written enough for now...