>>>>> "beliavsky" == beliavsky <[EMAIL PROTECTED]> writes:
beliavsky> I think the OO way is slightly more obscure. It's
beliavsky> obvious what x = reverse(x) does, but it is not clear
beliavsky> unless you have the source code whether x.reverse()
beliavsky> reverses x or if it returns a reversed list.
What make it so clear to you that reverse(x) will always return a
reversed list rather than reversing x in place and return nothing?
beliavsky> It is clearer and more concise to write
beliavsky> z = reverse(x) + reverse(y)
beliavsky> than
beliavsky> x.reverse()
beliavsky> y.reverse()
beliavsky> z = x + y
This isn't anything to do with OO programming. It is something about
using in interface that your audience expects. You have exactly the
same problem whether you are using procedural or OO style. It might
be a case for functional programming, but that's something off-topic.
beliavsky> Furthermore, if in Python the algorithm for the reverse
beliavsky> function applies to many kinds of objects, it just
beliavsky> needs to be coded once, whereas a reverse method would
beliavsky> have to provided for each class that uses it (perhaps
beliavsky> through inheritance).
That the reverse() wants to be a function doesn't mean that the thing
that reverse() operate on doesn't want to be an object. So this isn't
very clear a problem about OO style vs. procedural style, but instead
a problem about "generic" programming style vs. "concrete" programming
style. On the other hand, if the thing that reverse() operate on
isn't an object sharing the same interface, it will be more clumsy to
implement a generic reverse() that works for all the different kinds
of object---even if they share similar interfaces. Try to implement a
generic "reverse" in C when the different type of containers are
encoded as different style struct's accessible from different
function, and you will understand what I mean. So this is,
marginally, a case *for* OO style.
Regards,
Isaac.
--
http://mail.python.org/mailman/listinfo/python-list
