Another newbie question

[Antoon Pardon]

Op 2005-12-11, Steven D'Aprano schreef <steve at REMOVETHIScyber.com.au>:
> On Sat, 10 Dec 2005 15:46:35 +0000, Antoon Pardon wrote:
>
>>> But I *want* other classes to poke around inside my implementation.
>>> That's a virtue, not a vice. My API says:
>>>
>>> "In addition to the full set of methods which operate on the coordinate
>>> as a whole, you can operate on the individual ordinates via instance.x
>>> and instance.y which are floats."
>> 
>> Yikes. I would never do that. Doing so would tie my code unnecesary
>> close to yours and would make it too difficult to change to an other
>> class with a different implementation like one using tuples or lists
>> instead of a seperate x and y instances.
>
> Do you really think that my class and some other class written by
> another person will have the same API?

If both writers try to implement the same kind of object I would
think the API would be very similar yes.

> If you change from my class to
> another class, the chances are that the interfaces will be different
> unless the second class writer deliberately emulated my class interface.

So, lets say I have one class where you can do P1 + P2 and an other
class where you have to do P1.move(P2). If it is basically the
same kind of class but with a different API I just write a wrapper
and I am done unless of course I messed with the internals and
the internals in the second class are vastly different.

> To class users, there is *no* difference in consequences between me
> changing my published API by removing named attributes x and y from my
> class, and me changing my published API by removing or changing methods.

Yes there is. Methods are just names, if you just have different names
for the same functionality all you need is write a wrapper to translate
one name into an other.

If you no longer have an x and y attribute but a 2 element tuple,
then things aren't that easy to repair.

>>> Your API says:
>>>
>>> "In addition to the full set of methods which operate on the coordinate
>>> as a whole, you can operate on the individual ordinates via methods
>>> add_x, add_y, mult_x, mult_y, sub_x, sub_y, rsub_x, rsub_y, div_x,
>>> div_y, rdiv_x, rdiv_y, exp_x, exp_y, rexp_x, rexp_y...; the APIs of
>>> these methods are: ... "
>> 
>> Who in heavens name would need those? Maybe there is no x or y because
>> the implementation uses a list or a tuple, maybe the implementation uses
>> polar coordinates because that is more usefull for the application it
>> was planned for.
>
> 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.

-- 
Antoon Pardon