Subject: Re: [boost] A design for geometric objects
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2008-11-13 19:48:43
>There is a natural subtyping relationship between geometric objects.
>Deriving a square from a rectangle is usually frowned upon in OOP,
>because it can easily break the Liskov Substitution Principle if the
>objects are mutable.
>Making them immutable, however, solves the issue altogether.
Now, finally, I see your point.
Clearly if a rectangle output is expected you cannot pass it a mutable square to hold the result, but making such syntax illegal by preventing the generic API from modifying objects seems like a drastic measure. It eliminates more than half the utility of the mechanism.
The polygon_90 and polygon in my library are similar to your rectangle and square example. There is no inheritance relationship that does not violate Liskov's substitution principle, but my polygon inherits from polygon_90. Right now, my library does not protect the user from invoking an undefined behavior by passing an arbitrary angle polygon as input into a function that expects an axis-parallel polygon. This is a troubling lack of static type safety that didn't bother me much before now, but should have.
Overall, I've been frustrated that there is little to be gained from inheritance. The only benefit at this juncture is it saves me from writing a handful of functions in the few cases where I use it. It would be reasonable to eliminate inheritance and provide explicit overloads of each function required. Such a change would actually be relatively little code change in my library.
The effect of static polymorphism of geometry objects in the API can be achieved by explicitly overloading all functions for all types that make sense. That allows us to achieve the exact semantics that we are after.
Unfortunately, it is a huge effort to provide explicit overloads for all possible types. The number of types in the system needs to be kept down to keep the implementation effort tractable, but doing so could easily lead to a library that favors some application domains over others.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk