mal wrote:
Mr. Meyers presents some very well-reasoned arguments against the everything-should-be-a-method mentality.
Note that the motivation for turning to string methods was that of migrating from strings to Unicode. Adding Unicode support to the strop C module would have caused very complicated code -- methods helped by enabling polymorphic code which is one of the great advantages of writing software for an interface rather than an implementation.
as Alex pointed out on comp.lang.python, the first if-clause in Meyers algorithm is: if (f needs to be virtual) make f a member function of C; which probably covers the join case pretty well...
Note that functions can make very good use of methods and thus implement polymorphic functionality -- this is not about methods vs. functions it's about methods to enable polymorphic functions.
a bit further down, the algorithm goes: else if (f can be implemented via C's public interface) make f a non-member function; which covers all remaining non-trivial functions in the string module... (okay, you could get around this by renaming the method to something a bit more annoying; let's say the "public interface" contains a virtual method called "use_myself_to_join_sequence", in which "join" could be a non-member convenience function using nothing but the public interface. but that's just silly...) ::: fwiw, I still think that Meyers article cannot be fully applied to Python, since he's ignoring the case: else if (f can be implemented via C's public interface, but may have to be overridden by a subclass to C) make f a member function; this isn't a problem in a language that supports function over- loading (see the interfaces/packages section in meyers article), but as we all know, Python doesn't... </F>