[modules] How to convert pools, was: Re: AW: AW: [modules] Top 10 ways in which the modules system sucks

Henrik Gedenryd h.gedenryd at open.ac.uk
Sat Feb 2 21:41:18 UTC 2002


Andreas Raab wrote:

> Henrik,
> 
>>> Object subclass: #MumbleObject
>>> instanceVariableNames: ''
>>> classVariableNames: 'MumbleClassVar'
>>> poolDictionaries: 'TextConstants'
>>> category:'Foo-Bar'!
>> 
>> My guess is that this is because Pools don't exist any longer
>> :-/ because they are unnecessary and Modules can do the same thing
>> in a better way. TextConstants, and the other pools, are now Modules.
>> You can send the messages.
> 
> Okay, thanks for the clarification. If so, then I need to report two
> bugs and ask a question. First bug is that some classes still use pool
> dictionaries (oops) and I believe that the conversion process didn't
> quite get them right.

Ok that surely wasn't my intention so info on what they are (or a fix :-) is
appreciated.

> How do we fix those in particular considering that
> custom images may contain many classes that may reference pools?!

Those class that already use pools should continue to work fine until you
recompile pool-referring code--I don't actively destroy existing pools. But
creating classes that use pools wouldn't work anymore.

And to be able to recompile (former) pool using classes you need to

A) convert their pools into (pool) modules.

B) Convert existing code that accesses the pool dictionaries directly. This
is typically only pool intialization code (unless you write naughty
self-modifying code or some such ;-).

To do A you create a subclass of ModuleRefactorer, and fill in the info by
overriding #newModulesForPools. Search for the existing implementor of that
message to see how to do this. Check ModuleRefactorer 'convert pools'
category to see the code that does this (but you shouldn't need to know how
it is done). You run this code by executing "<TheRefactorerClass> run". Save
the image before running that--you'll probably need a couple of tries to get
it right.

To do B, you change the pool initialization code that sets up the pool vars
to define them as vars in the pool module instead. The CS released as update
4681 holds the code that converts the necessary code in the standard image.
That CS should be a good reference point for doing this, it holds
conversions both for simple pool init code and for some more naughty code.

> The
> other bug is that apparently the set of dictionary messages sent from
> the compiler is not understood by modules. I don't think they should be
> understood (modules are _no_ dictionaries) or at least in a rather
> limited way (through their exported names?!).

Right, I intentionally did not imitate the Dictionary protocol.

> But we need to fix those
> users of dictionary access messages and the above exposes one of them.

What are the dict. access messages you are thinking of? Are they the pool
initialization code? If so see above, otherwise get back to me.

> The question is: What do we do about backward compatibility?! In my
> case, the above was just a very simple example of a CS that I was
> actually filing in, which used TextConstants and was _supposed_ to just
> work. I think we need to aim at backward compatibility at the point of
> just filing in classes - it should not be required that in order to just
> file in an old bit of Squeak which (for instance) happens to use pool
> dicts we need to rewrite all the references in the old code.

Umm, there is unfortunately no simple way to do any automatic conversion,
but simple pool initialization code should be simple to convert.

A possible solution is to make pools fileIn-able again. It would mainly mean
putting back pool lookups in the code that binds upper case variable names
to values. It's on my list (though a list of what, I don't know).

But you won't be able to use this code as proper module code anyway as pools
break modularity.

Henrik




More information about the Squeak-dev mailing list