Another newbie question

[Antoon Pardon]

Op 2005-12-12, Steven D'Aprano schreef <steve at REMOVETHIScyber.com.au>:
> 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.

In point of fact, the class I have can do just that. 

> 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?

How the user specifies his values and how they are internally stored
are two entirely different issues. The fact that the use specifies
his numbers in Morse Code or written out in words doesn't imply
they have to be stored in that form. Just as the user supplying his
points with x,y coordinates doesn't imply the implementation has
to work with carthesion coordinates.

> 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. 

Indeed different kind of applications work better with different
kind of implementations. That is the whole point, use the same
API for the same functionality even if the implementation is
different, so I can solve the same kind of problem with the same
code, independant on whether I have 2D point 3D points or maybe
sparse 10 000 000D points.

> 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.

There is a difference between deciding on a model and exposing your
model. If you are working with certain kinds of objects, the solution
should more or less be independant of the model chosen to implement
the object. If you need to expose the model in order to solve particular
problems with your objects, I would think you either have chosen the
wrong kind of objects or a bad implementation of them to solve your
problem.

-- 
Antoon Pardon