Re: One Ring to Bind Them

"Tony Douglas" <tonyisyourpal_at_netscape.net> wrote in message news:bcb8c360.0407020159.9249ddf_at_posting.google.com...
> "Marshall Spight" <mspight_at_dnai.com> wrote in message news:<H%oDc.98848$2i5.74802@attbi_s52>...
> > "Tony Douglas" <tonyisyourpal_at_netscape.net> wrote in message news:bcb8c360.0406180909.7fe81c07_at_posting.google.com...
> > Hear hear! Bravo! Bravo!
> >
> > Please, tell my what is your *other* main bugbear with TTM.
> >
>
> My other main bugbear with TTM was over the type system, but I must
> admit I'm softening my line on that, but not possibly for the normal
> reason. I felt that the facility to have mulitple possible
> representations for a type only served to create complications,
> without adding a lot to the party.

It doesn't seem hugely useful to me, either. If you consider the canonical example of the CartesianPoint(int x, int y) vs. the PolarPoint(float theta, float r), using the one constructor with the other implemenation is annoyingly expensive. You have a leaky abstraction problem, in that you can't get away from the fact that your underlying type-implementation has performance consequences for the choice of interface.

Alternatively, you could have a type Point, and types CartesianPoint <: Point, and PolarPoint <: Point, which all support the same set of methods/operators/what have you. You still have the leaky abstraction problem with interface calls; getting the radius is much easier with PolarPoint than with CartesianPoint; getting the X or Y attributes is easier the other way. But it seems like less of an issue even so. I suppose one could also declare that constructing Point is done with one or the other Point subclass.

> Still
> not a great fan of type hierarchies though, although I can grudgingly
> accept some rationales for them.

What about polymorphism? Polymorphism is the best thing about OO, and a good thing in general. You can't have subtype polymorphism without subtypes.

Marshall Received on Sat Jul 03 2004 - 02:59:09 CEST