Reconsider TypeObject equals()/hashCode()

TypeObjects are non-final for the purposes of subtyping, and thus have a non-final hashCode()/equals()/toString() methods.

As such they are extensible to potentially include other fields and have different equality contracts – and are using getClass() for their equality contract.

This seems counter-intuitive in their basic use, where they are being derived – derived TypeObjects do not override none of these methods. Furthermore toString() method in the first derived object uses strictly its class for identity.

The combination of these leads to quite surprising behavior:

• equals() between base type and its derived type does not work, but
• the base type can freely be substituted by the derived type, and
• when such substitution happens toString() will not identify the object as being of derived type

From YANG perspective, both are just data, and hence as long as their canonical value matches, they are considered equal – but then YANG does not really consider substitution as each instantiation defines a particular type, which is to say the set constraints that are acceptable and nothing else.

I think the intent here was that the first derived type creates a type domain and binds the equality contract in terms of itself and the value it holds – which would match YANG semantics and reduce surprises – but in that case we should really define equality in terms of instanceof and make hashCode()/equals()/toString() final.

An example of a model which is impacted by this change looks roughly like this:

model example {
  typedef base-type {
    type string;
    length 1..5;
  }

  typedef derived-type {
    type base-type;
    length 2..5;
  }
}

Under the change proposed by this issue, the two generated objects will compare as equal if they contain "abc", whereas currently they do not (due to having a different class).