[Squeakfoundation]An architecture for sustainable Squeaking

[Henrik Gedenryd]

Bob Hartwig wrote:

>> but this creates spurious sideways
>> interactions between modules. Perhaps only applications should be allowed to
>> do this.
>> 
> I've heard this before, by intelligent people, but I haven't seen
> convincing evidence.  I've made several base class extensions over the last
> 8 years, and have never been bitten.  Can you give an example of the problem?
> 
> Thanks,
> Bob

Well, this is essentially the problem addressed by allowing separate modules
use the same selector for different methods. If you have that ability then
there's no problem I guess.

We'll probably need to allow it, but I don't realistically believe this
dual-methods thing will be among the first things we choose to spend time
on. It's really a quite rare special case. I think we might classify it as
allowed but preferrably avoided practice (cf. adding methods to Object). The
"further in" toward the core, the more we'd try to avoid it unless
warranted.

But I though about this example, in code inside a module:

'bla bla' selectorDefinedTwice

Here, the Compiler creates a String. Are present implementations that allow
this smart enough to instantiate a String as it is known in the creating
namespace, with the right method defined? Because the Compiler's namespace,
when the literal-compiling method is defined, would certainly not know of
either of the two definitions.

The general point is that this string literal is just an implicit reference
to the String class and might not be caught by the several-definitions
functionality, as an explicit reference, say,

 String newWith: 'bla bla'

would.

But this is a tiny pixel in the big picture.

Henrik