Re: OO should break when broken(was re: the benefits of immutability)

[address@hidden]

Quoting Colin Putney <cputney@wiresong.ca>:
> [...] Subclasses are subtypes, and do have a is-a, a-kind-of
> relationship with their parents. The problem is that geometric types are
> defined differently than class types.

Are they? The set of circles is-a subset of the set of ellipses. Every
circle is-an ellipse and every circle is-a-kind-of ellipse.

> Shapes are defined in terms of constraints. To create a subtype, you
> add constraints. So a quadrilateral is a polygon with four sides, a
> rectangle is a quadrilateral with right angles at the vertices, a
> square is a rectangle with sides of equal length. Classes types are
> defined in terms of state. To create a subclass you add state. (We'll
> ignore behaviour for now.)

I think that the above reasoning has two major errors.

1. To create a subclass does not require to add state. However, when one
adds state in a subclass, one usually constraints the superclass state in
respect to the additional state in the subclass. More formally, if the set
of valid states of the superclass is V(p) and the set of valid states of
the added state in the subclass is V(b\p), then the set of valid states of
the subclass is generally a subset of V(p) x V(b\p), where x denotes the
cartesian product.

More strongly, I would claim that a subclass is only meaningful if the set
of valid states is a proper subset of V(p) x V(b\p), because otherwise the
added state essentially does not add any semantic information and you
could just as well use a simple pair to represent the same information
without subclassing.

Stated in another way, the essense of a subclass is to constrain the set
of states of the superclass.

2. One just can not generally ignore behaviour (= functions and procedures)
when dealing with software. Representational (data) hierarchies are useless
unless they satisfy useful invariants that can be exploited by behavioral
entities (= functions and procedures).

> To model a shape with a class you have to include enough state to cover
> the range of variation allowed by the constraints. The more specific the
> geometric subtype, the more constraints it has, and the less state is
> required to model it. So the type hierarchies of shapes and the classes
> that model them have an inverse relationship. That's why all circles are
> ellipses, but all Ellipses are Circles.

So, would you derive a class representing Complex numbers from a class
representing Real numbers? Why or why not? Why would or wouldn't you
treat the Ellipse-Circle situation in the same way?

Regards,
  Vesa Karvonen