Walter: extend existing classes with new methods?

[Bill Baxter]

Sorry to drag this up again, but I was out of town for a while.

Marcio wrote:
>   You want String to have a new method, say asURL. Or findReplace. Or 
> whatever. Not a new String subclass. You want to add functionality to 
> String.
> 
>   You want all objects to understand dumpOn (aStream). Say you are 
> writing a persistent framework. You need to add methods to Object.

The thing that I don't get about this is what happens if code A and code 
B both decide to add an 'asURL' method to String?  Or 'dumpOn' to Object?

With a function [e.g. asURL(aString), dumpOn(obj,stream)] these things 
can be disambiguated by using fully qualified names [myModule.asURL, 
yourModule.asURL], but if you go and make it a method on the base class 
[String.asURL()], you're effectively putting in the namespace of that 
class, right?  And so you're suceptible to name clashes with anyone who 
wants to add methods to the same class.

Do you make it so that the lookup is done local to the calling module? 
So that if module B adds a method to String, only module B can see that 
method?  I don't see how that can work implementation-wise, though.  How 
will I know to use that table instead of the default one when handed 
some arbitrary pointer to an object that may or may not be derived from 
String?  -- without adding a bunch of extra explicit type checks, I mean.

It's a very interesting idea. I guess I still just don't see how it can 
work in a statically typed language where dispatch is done with vtable 
lookup.

--bb