Hi tim


I think that this is an interesting issue. I always got problems 
because Pool are really static and led to all kind of strange bug when 
I tried to changed their values.

Is the value of the associated variable hardcoded in the method frame 
or the key in the dictionary. Once I tried to use them seriously in 
VW30 and I realized that they
were really static and not for what I needed.

In general I tried to avoid to use them. But this is not really a 
solution.
I like the idea of having

	classVariableNames: ''
> 	poolDictionaries: Text textConstants

However it does not solve really the problem of their static aspect.
Now if we avoid to use them, we will introduce other class that will 
play their role
and trasnform implicitly a static access (compile time) for a dynamic 
invocation.
Is my interpretation correct?
Then what is its cost?

Stef



On Friday, April 11, 2003, at 11:40 PM, Tim Rowledge wrote:

>>
> A few days ago I complained about how filing out a ChangeSet did not 
> include the pool dictionaries used by classes originally added by the 
> file that was used to create the change set.
> Umm, trying to explain that a bit better:-
> B3DAcceleratorPlugin uses a pool dictionary, shared with several other 
> classes.
> fileout B3DAcceleratorPlugin - the definition of the pool stuff is 
> included
> later...
> file it into an image with the above removed, creating a new changeset.
> Do work.
> file out changeset.
> Whoops, no pool dictionary stuff in file!
>
> This seems to me to be a big annoyance to anyone maintaining a 
> package. Looks to me like it adds a sizable burden of having to 
> fileout added classes manually and assembling packages. Yuck.
>
> What should we do about pool dictionaries? They've always been a bit 
> of a pain to live with.
>  - we could stop using them.
>  - we could change changeset fileout to include the definition along 
> with any added class definition
>  - we could change changesets so that adding a class means no method 
> changes to that class are recorded separately (which used to be the 
> case once upon a time) and thus the entire class is written out 
> (including pools)  with the changeset.
>
> ...and probably many other possibilities.
>
> I think one of the big irritations with pools is that they don't 
> really belong to anyone and so it is tricky to work out who should do 
> anything with the definition. The state is only in the actual object 
> and there may be no record at all of what should be in there. If you 
> fileout a class that uses a pool, should it really include a 
> description of the pool? After all, other classes could be using it 
> and changing the values or adding more. Perhaps if a changeset 
> includes <all> the classes that refer to a pool one could feel safe! 
> In many respects I'd prefer to use class variables and access them 
> (for other classes) by good old message sends but I can imagine some 
> people might feel that this would impact performance too much.
>
> An interesting possibility came up whilst talking about this with 
> Craig, one that might provide some useful leverage; change the class 
> defn message to cope with  something like:-
> Object subclass: #Fooble
> 	instanceVariableNames: 'alpha bravo charlie '
> 	classVariableNames: ''
> 	poolDictionaries: Text textConstants
> 	category: 'Tools-Changes'
> ie instead of a string that names global (that is assumed to be a 
> suitable dictionary) we pass an actual suitable object.  This would at 
> least provide some sort of ownership for the pool (ie Text class in 
> this case) and a place where it is created and maintained - and filed 
> out!
>
> Now this is only a rather small part of the work of maintaining 
> packages so let's not get too hung up on small nitpicking about pools, 
> but a solution to the real problem does seem t ome to be pretty 
> important.
>
> tim
> -- 
> tim at sumeru.stanford.edu
>
>
>
Prof. Dr. Stéphane DUCASSE
http://www.iam.unibe.ch/~ducasse/
  "if you knew today was your last day on earth, what would you do 
different? ...  especially if,
  by doing something different, today might not be your last day on 
earth" Calvin&Hobbes

"The best way to predict the future is to invent it..." Alan Kay.

Open Source Smalltalks: http://www.squeak.org, 
http://www.gnu.org/software/smalltalk/smalltalk.html
Free books for Universities at 
http://www.esug.org/sponsoring/promotionProgram.html
Free Online Book at 
http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks.html