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>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4