On 2005-12-10, Steven D'Aprano <[EMAIL PROTECTED]> wrote: > On Sat, 10 Dec 2005 01:28:52 -0500, Mike Meyer wrote: > > The not-so-wise programmer takes abstraction as an end itself, and > consequently spends more time and effort defending against events which > almost certainly will never happen than it would have taken to deal with > it if they did. > > Do you lie awake at nights worrying that in Python 2.6 sys.stdout will be > renamed to sys.standard_output, and that it will no longer have a write() > method? According to the "law" of Demeter, you should, and the writers of > the sys module should have abstracted the fact that stdout is a file away > by providing a sys.write_to_stdout() function.
I find this a strange interpretation. sys is a module, not an instance. Sure you can use the same notation and there are similarities but I think the differences are more important here. > That is precisely the sort of behaviour which I maintain is unnecessary. > > > >>> The bad side of the Guideline of Demeter is that following it requires >>> you to fill your class with trivial, unnecessary getter and setter >>> methods, plus methods for arithmetic operations, and so on. >> >> No, it requires you to actually *think* about your API, instead of >> just allowing every class to poke around inside your implementation. > > 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. > 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. Sure a way to unpack your coordinate in a number of individual ordinate variables could be usefull for when you want to manipulate such an individual number. > My class is written, tested and complete before you've even decided on > your API. And you don't even really get the benefit of abstraction: I have > two public attributes (x and y) that I can't change without breaking other > people's code, you've got sixteen-plus methods that you can't change > without breaking other people's code. No he would have none. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
