See below.  Outlook does not support normal quoting.

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.

#MAL I think one of the ideas is that you should be able to load a
#MAL module without modification.  In particular if the idea is to host
#MAL multiple applications in one image, no modification should be required.

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.

#MAL While having the module name in the selector reduces collisions
#MAL it also means that the selector does not read as well as regular
#MAL selectors.

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.

#MAL If you mean replacing a method in one module by a modified method
#MAL in another module that has a very different semantic.  That is more
#MAL a matter of having the loader be able to do that.  The methods do not
#MAL co-exist.  If you mean to
#MAL implement a selector defined in another module, that will surely be
#MAL required in any solution.  Not all methods can be private, just as a
#MAL class in a module would need to be able to override a method in the
#MAL base class of any classes it defines.

-Ralph Johnson