[squeak-dev] Is prompting to make a pool dictionary useful?

Frank Shearar frank.shearar at gmail.com
Tue Jan 7 13:30:30 UTC 2014


On 7 January 2014 12:42, Bert Freudenberg <bert at freudenbergs.de> wrote:
> On 05.01.2014, at 22:45, Chris Muller <asqueaker at gmail.com> wrote:
>
>> On Sat, Jan 4, 2014 at 8:31 AM, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>> On 02.01.2014, at 11:47, Frank Shearar <frank.shearar at gmail.com> wrote:
>>>
>>>> Class >> #sharing: asks a user if they want to automatically create a
>>>> pool dictionary. Under what conditions would you _not_ want to create
>>>> the pool dictionary?
>>>
>>> In case you misspelled the name. It's really much more common to create the pool first and *then* add it to a class. I've never run into that dialog.
>>
>> If someone misspelled it they could just change it to what they
>> wanted, couldn't they?
>
> Apparently not, at least not in that method.
>
>>>> And why does it create a Dictionary, not a SharedPool? (I see that "we
>>>> do not fileout SharedPool type shared pools for now'", according to
>>>> Class >> #fileOutPool:onFileStream:.)
>>>
>>> They used to be simple dictionaries, and still can be. The code is not really wrong.
>>
>> Not blowing up at least.  But is there a reason to need both cases as
>> a Dictionary or a SharedPool or would it be better to decide on one or
>> the other exclusively?  (in 4.6, that is)
>
> As Tim wrote, there are some obnoxious pools in the image that are not easily converted to a static form. A SharedPool is really a holder of a limited number of constants. But e.g. TextConstants is everything but constant - every font you install creates a new entry, which would correspond to a new class variable in the SharedPool. Installing a font should not modify code, agreed? So that's why TextConstants is still a dictionary pool.

As a counterpoint, this method will only affect the creation of _new_
pools: so should these _new_ pools be Dictionary instances, or
SharedPools?

frank

> - Bert -


More information about the Squeak-dev mailing list