goran.krampe at bluefish.se wrote:

> It did ask to create a pool
> during the B3D stuff.
Ah, yes, PoolDictionaries again. What fun they provide, what potential
for profit for the therapist!

I've only taken a really hard look at the pools involved in the VMMAker
stuff so far and I found three quite different ways of handling them
besides the 'obvious' one (to whit, create a Dictionary and fill it in a
workspace and then just use it in classes).

First, add some class methods to create the pool in a fairly direct
manner in the 'application' related class. This is what Luciano did in
the Klatt speech system.

Second, class methods creating the pool in a somewhat more complex
manner (more checking for Undeclared, split up more into sections etc)
in the 'plugin' related class. This is what Andreas did for the Balloon
stuff.

Third, a separate class to define and fill the pool. This is what
Andreas did with B3DPoolDefiner for the B3D stuff.

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?
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.

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:poolDictionaries:categ
ory: 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.

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.

tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: SCS: Spurious Cold Start