PoolDictionary handling (was Re: [ANN] "Upgrade to 3.6 Full Image" package on SqueakMap)

Andreas Raab andreas.raab at gmx.de
Tue May 13 19:44:11 UTC 2003


Hi Tim,

> I quite like that last idea as it breaks out what can be quite a bunch
> of code (certainly when a pool has a large number of entries) into a
> class that explicitly has the job of taking care of the pool. It still
> leaves the problem of where to include it in package terms though.
> 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
;-)

> It's needed by both. It could go in both (the code is written 
> in such a way that it would not mess things up) but what happens
> if some value is changed or added - somebody needs to remember and
> make sure it is correlated correctly. It could go in a separate
> package if we can rely on prerequisites functioning.

Which would be my preferred way of handling it. Alternatively, we might get
'fancy' about installing it conditionally but that seems to be messy in the
long term.

> I think I'd like to propose that _all_ pools be created and managed in
> this manner. A trivial hierarchy of pool definer classes (a root one
> that gives all the needed framework and explanation plus concrete
> subclasses for actual use) and perhaps a classbuilder change to insist
> that any pool actually has a definer class?
> 
> There is a potentially interesting extension to this that may 
> be viable; have the pool be an instvar of the definer and have
> the definer classes name be the key used in
> subclass:instanceVariableNames:classVariableNames:poolDictiona
> ries:category: instead of just a global name for the dictionary.
> There seems to be only a few places where Dictonaryness is
> explicitly assumed for a pool (including a few cringworthy
> cases of #isKindOf:)  and adding #associationAt:ifAbsent:,
> #keysDo:, #includesKey: would probably suffice.

*Personally* I think we should completely abandon the use of the dictionary
protocol for resolving names. 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 never shipped it (as there's some potential for damage and I didn't test
it too heavily) but it worked and using the single protocol makes this task
much easier as it is clear what the client is asking for (I never know
whether #scopeHas:ifTrue: answers the binding or a boolean) and it means you
only have to implement a single message if you want to define any kind of
name space for use with the compiler. So that a 'pool' could be any object
that knows how to resolve a name using #bindingOf:

(as you may guess, the above was the intent of that change, e.g., rather
than using dictionaries you might have some smarter object so that the
'pools' can be ordered lists of name spaces instead of just some globals)

I did also consider going a little further by instead of handing you a
'naked association' giving you an object that describes the kind of thing
you are resolving. An instance variable, a class variable, a global - in
other words a description for a parse node. But I wanted to figure out how
complex such a change is without having to touch too many things; once you
got it down to one protocol this kind of change is trivial. As it turned out
the effort required was manageable.

> PoolDictionaries are definitely at the top end of my list of irritants
> right now. Anybody else with good ideas on how to handle them please
> speak up.

See above. The main problem is to figure out where they *should* live and
making them explicit instances of (for example) some class SharedPool or so
would certainly help. If we get the protocols involved down to a reasonable
amount then this should be relatively simple.

Cheers,
  - Andreas



More information about the Squeak-dev mailing list