Hi tim and andreas

We are interested to help fixing this issue. Could one of you summarize 
the problems because I followed
all the emails related to this issue but I'm sure I understand the 
problem exactly and the pros
and cons of each solution.

This way once this clarification is done we can take some actions.

Stef

On Wednesday, May 14, 2003, at 12:12 AM, Tim Rowledge wrote:

> "Andreas Raab" <andreas.raab at gmx.de> wrote:
>
>>> Should B3DPoolDefiner 'live' in the B3D package or the VM
>>> code package?
>>
>> If it has to live in a single place then it should live in the B3D 
>> package
>> and not the VM code package as VM building is in my understanding a
>> relatively rare activity (well, not for the two of us but for most 
>> people
>> ;-)
> Well it was an easy case, of course, though not all of them are so
> solvable. Using 'Smalltalk poolUsers' will get a list of all the
> findable dictionaries that seem to be used as pools, along with user
> classes and methods. Some of them are really quite ugly looking
> collections of tentacles. Or eleventacles.
>
>>  Some time ago (in the age of 3.3a modules) I
>> did a change which completely replaced all the variants of 
>> #scopeHas:ifTrue:
>> /#at: / #associationAt: / #youNameIt with a single protocol for 
>> resolving a
>> name - namely, #bindingOf: (which answers a binding -association or 
>> alike-
>> for a given key or nil if it can't be resolved) and modified the 
>> compiler
>> appropriately.
> I think this sounds worth another look, especially if the KCP team can
> make time to try it out. The current scheme actaully has a couple of
> nasty loopholes I stumbled upon a while ago; I think I explained at
> least some of them in mails back then.
>
> The one advantage I think might attach to my suggestion is that it 
> would
> slide in with almost no changes and very little scope for mistakes
> beyond needing to implement another method or two. Your suggestion 
> would
> be cleaner for the long run. A merge of the two might really solve some
> problems - use the hierarchy of pooldefiner/sharedpool/whatever class 
> to
> combine the initialisation of the values and the #bindingOf: protocol 
> to
> clean up the needs and implementation. Simple to use, document and
> explain; what a concept.
>
> Then we beat up Goran (some more) to provide suitable dependency 
> support
> in SM1.1 and alakazaam, 'tis done.
>
> tim
> -- 
> Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
> Useful random insult:- Always responds to "Make Money Fast" postings 
> on the Net.
>