On 5/26/06, Michael Latta <lattam at mac.com> wrote:

> I can see the need to have methods that are defined by different authors
> that happen to use the same selector, but are really different methods.  As
> the size of libraries grows this is more and more likely.  I suspect that
> method collision is far more likely and more of an issue than class name
> collision.  Possibly what is needed is method name prefixes more than class
> name prefixes?

I've been programming in Smalltalk off and on for twenty years.  I've
taught a class that used it at least once a year.  Method collision
that could be solved by private selectors is pretty rare.  Class
collision is more common, but still isn't that common.

I've seen three types of method collisions.  One is where people
extend a class like Collection with new methods that extend the notion
of what a collection is.  These methods are not based on the users of
the class, but are intrinsic to the class.  When two modules try to
add methods with the same name, they usually do more or less the same
thing.  If they don't do the same thing, it is easy for one module to
rename its version of the method.  It is not common, but private
selectors could prevent it.

Another potential type of method collision is where a module needs
some default behavior in all classes and so adds a method to base
classes like Object.  These methods really have little to do with
Object and are only going to be sent by the module,.  Often their name
is based on the module, and so the chance of collision is vrery small.
 I don't think I've ever seen this kind of collision, though I often
make this kind of extension of existing classes.

The third type of method collision is where a module changes an
existing framework by overriding some of its methods.  This is the
most common kind of method collision, but private selctors wouldn't
help, because the whole point is to use the same selectors that the
framework is already using.

-Ralph Johnson