Another newbie question

[Steven D'Aprano]

On Mon, 12 Dec 2005 12:12:46 +0000, Antoon Pardon wrote:

>> And maybe it isn't a Coordinate class at all, hmmm?
> 
> Indeed it isn't. It is usually a Point class.
> 
>> An ordinary, Cartesian, real-valued Coordinate is a pair of ordinates, an
>> X and Y ordinates. That's what it *is* -- a coordinate class without X and
>> Y ordinates isn't a coordinate class, regardless of how they are
>> implemented (via properties, named attributes, or a whole bucketful of
>> helper functions).
> 
> That is why a coordinate class is a bad idea. It mentions an
> implementation in what should be an abstract idea like a 2D point.
> 
> In that case if you find out that you are manipulating your objects
> in ways, for which polar coordinates are better, you can transparantly
> change the implementation.

That's a great idea Antoon, but you don't go far enough. Why limit
yourself to something as concrete as a pair of floats? What we actually
need is an even more abstract class, one which can hold an arbitrary
number of ordinates, not just two. And why limit ourselves to floats? What
if the user decides that he wants to specify ordinates as written English
numbers like the Morse Code for "thirty-seven point three four", coded in
base64?

For that matter, now that we have an arbitrary number of ordinates, why
limit yourself to list implementation? Perhaps a better implementation is
a tree structure, or an orchard, or some sort of mapping? Or some hybrid
of all three. 

And the methods, well, the methods. It is so limiting to be forced into
one specific API, with names like instance.move(), rotate(), reflect() and
so forth. What if I should change my mind, and decide what I really need
is a message-passing model instead? We better write some more code
isolating the methods from the user, making the class even more abstract
again, just in case we should ever choose to change those methods'
interface.

Heaven forbid that we should actually decide on a model for our class,
ever. Sure, we'll end up having to implement a Turing-complete programming
language as our class, but I think we'll all agree that that cost is a
small price to pay for something which is sufficiently abstract.



-- 
Steven