Howdy Andrew!

Andrew P. Black wrote:
> At 21:16 -0400 2001.08.15, Stephen Pair wrote:
> 
>> Simple example:
>>
>>     - "Package A" overwrites the method #add: on OrderedCollection.
>>     - The method doesn't work properly and brings the system to its
>> knees (try it!)
> 
> 
> I suspect that I still don't fully understand the problem.  If I want to 
> change the meaning of add: on OrderedCollection, and I am allowed to do 
> so, then indeed a bug in my new method will bring the system to its 
> knees.  How could it not?  If I don't intent to change the meaning of 
> add: on OrderedCollection, then I refrain from compiling a new add: 
> method on OrderedCollection, and, presto, the system is still happily 
> hobbling about on its heels, as usual ;-)

Oh sure, take the EASY way out!

> OK, so suppose that I _do_ want to change OrderedCollection>>add:. And I 
> want to test it first.  I do this by building a subclass of 
> OrderedCollection, redefining add:, and testing it.  If I don't test 
> thoroughly enough,  when I promote that add: method up into 
> OrderedCollection, the system dies horribly.  This will teach me to test 
> more thoroughly next time.

It would also teach you to stop playing around, and that is evil.

> Alternatively, I could write a new method called newAdd: on 
> OrderedCollection, test it, and then change its name when I'm sure that 
> it works.  Are these approaches so bad?

Lots of hobbling about there, don't you think?

> Even though I don't understand the problem, I think that I do understand 
> the proposed solution well enough not to like it.  One of the really 
> wonderful things about Smalltalk is that method naming and dispatch is 
> very simple.  A message contains a selector.  It's really easy to see if 
> two messages have the same selector, or if a method matches a selector 
> -- the test is essentially string equality. Compare this with C++ or 
> Java or .NET, where the process may be compounded by overloading, the 
> identity of the package that declares the method, the number of the 
> arguments and their classes, and, I'm tempted to say, the phases of the 
> moon.  Why?  What does all this complexity buy these languages?

The primary benefit that you would get in Smalltalk would be a stronger 
isolation from attacks, whether intentional or not... I have loaded enough bits 
of code from enough different sources to have come to the realization that I 
really do want a clear picture of what they are going to try to do to my image 
before I load them.  Now, having that capability gets you quite far without any 
of this Symbol shenanigans.  But not all the way- you are still left with the 
occasional situation where you really do want to have two conflicting versions 
of the same method coresident within the same image.  In these cases, you find 
yourself acting as the arbiter, trying to figure out what the two conflicting 
parties were trying to do, and hopefully finding a solution that will satisfy 
both... when you are in that situation, life is *hard*, harder than it really 
ought to be.  If you can allow these two definitions to co-exist peacefully, so 
that the semantics of each are seen by those parties that expect those 
semantics, then you don't have to do this.  ( and yes, I've run into this 
before- saying that "we shouldn't be modifying the base" doesn't get you very 
far in the real world, where everyone else felt quite happy to do so.  Besides, 
sacred cows keep you from playing around, and that is evil. )

> In general, then, I will argue against anything that adds complexity to 
> the message send and dispatch semantics, not only from the point of view 
> of efficiency, but mostly from the point of view of wishing to maintain 
> Smalltalk's conceptual elegance.  That is why I like to hang out here.

There is nothing beautiful about the concept of wading through someone else's 
code, let alone several someone else's code, to figure out how to get the two 
parties back on speaking terms.  This is *not* beauty.

> If there is a real problem that Smalltalk's mechanism's cannot address, 
> I will argue for dealing with it in the tools, rather than complicating 
> the semantics of the language.  For example, suppose that it is really 
> essential to load two versions of the same package. Normally, the 
> methods changed in the second version one will just overwrite the 
> similarly named methods from the first, but there might be a switch to 
> stop this.  However, setting this switch would not change the dispatch 
> semantics: it would re-write the source code.  So the two versions of 
> add: would be renamed _v1_add: and _v2_add:, and the module loader would 
> generate a new add: method something like this:
> 
>     add: anItem
>         "automatically generated by the module loader on
>         2001.08.13 at 14:27 to allow OrderedCollection_v1 and
>         OrderCollection_v2 to coexist"
> 
>         thisContext containsPackage: #OrderedCollection_v1
>         ifTrue: [ thisContext containsPackage: #OrderedCollection_v2
>             ifTrue: [self error: 'Operating in a conflicting package 
> context'].
>             ^self _v1_add: anItem
>             ]
>         ^self _v2_add: anItem

Basically, that is what is proposed by Symbol spaces, but without all the extra 
code to support checking which package the sender was in... you just do an 
ordinary method lookup.  Symbols are objects.  Ordinary objects.  There is 
nothing special about them, other than the fact that they are guaranteed to be 
unique by class Symbol.  Each component space ( like an OasisModule ) can have 
its own symbol space.  The tricky part ( which I am certain *will* be tricky, 
because nothing else in Oasis has been trivial ) is to make it work smoothly, so 
that you can _remove_ the #add: method from your own module, and fall back to 
having the #add: lookup take place in OrderedCollection's environmnent.  But it 
may not be that bad at all.


> The advantage of this is that it slows down only those who use it, and 
> that there is no magic: if I need to understand why one method is 
> invoked rather than another, I can just read (or step through) some 
> Smalltalk code.

Basically, a tools issue.

> 
>     Andrew

Keep up the comments!

- les