Methods vs. Functions (Re: [Python-Dev] A house upon the sand)

[Fredrik Lundh]

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>