Is prompting to make a pool dictionary useful?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Is prompting to make a pool dictionary useful?

Frank Shearar-3
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?

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:.)

frank

Reply | Threaded
Open this post in threaded view
|

Re: Is prompting to make a pool dictionary useful?

Bert Freudenberg
On 02.01.2014, at 11:47, Frank Shearar <[hidden email]> 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.

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

Shared pools don't have to be SharedPool instances. These are just convenient for manipulating them using a class browser.

This piece of code would have to offer a choice, and if you wanted to create a real SharedPool, then you need to pick a class category for it, too. And if you touch the code, then offering a list of potential shared pools would be nice, and lead to less misspelling ;)

- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: Is prompting to make a pool dictionary useful?

timrowledge

On 04-01-2014, at 6:31 AM, Bert Freudenberg <[hidden email]> wrote:
>
> Shared pools don't have to be SharedPool instances. These are just convenient for manipulating them using a class browser.

Well, when we invented the SharedPool class idea Andreas & I both expected it to replace boring old dictionaries. I think we got as far as the rather awful TextConstants, saw what a mess it is and ran away, leaving the rest to the student.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- One flower short of an arrangement.



Reply | Threaded
Open this post in threaded view
|

Re: Is prompting to make a pool dictionary useful?

Chris Muller-3
In reply to this post by Bert Freudenberg
On Sat, Jan 4, 2014 at 8:31 AM, Bert Freudenberg <[hidden email]> wrote:
> On 02.01.2014, at 11:47, Frank Shearar <[hidden email]> 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?

>> 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)

Reply | Threaded
Open this post in threaded view
|

Re: Is prompting to make a pool dictionary useful?

Bert Freudenberg
On 05.01.2014, at 22:45, Chris Muller <[hidden email]> wrote:

> On Sat, Jan 4, 2014 at 8:31 AM, Bert Freudenberg <[hidden email]> wrote:
>> On 02.01.2014, at 11:47, Frank Shearar <[hidden email]> 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.

- Bert -





smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Is prompting to make a pool dictionary useful?

Frank Shearar-3
On 7 January 2014 12:42, Bert Freudenberg <[hidden email]> wrote:

> On 05.01.2014, at 22:45, Chris Muller <[hidden email]> wrote:
>
>> On Sat, Jan 4, 2014 at 8:31 AM, Bert Freudenberg <[hidden email]> wrote:
>>> On 02.01.2014, at 11:47, Frank Shearar <[hidden email]> 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 -

Reply | Threaded
Open this post in threaded view
|

Re: Is prompting to make a pool dictionary useful?

Bert Freudenberg
On 07.01.2014, at 14:30, Frank Shearar <[hidden email]> wrote:

> On 7 January 2014 12:42, Bert Freudenberg <[hidden email]> wrote:
>> On 05.01.2014, at 22:45, Chris Muller <[hidden email]> wrote:
>>
>>> 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?
Good point. Seems reasonable to encourage the use of SharedPools.

- Bert -





smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Is prompting to make a pool dictionary useful?

timrowledge

On 07-01-2014, at 7:28 AM, Bert Freudenberg <[hidden email]> wrote:
>> As a counterpoint, this method will only affect the creation of _new_
>> pools: so should these _new_ pools be Dictionary instances, or
>> SharedPools?
>
> Good point. Seems reasonable to encourage the use of SharedPools.

Definitely. And if someone with some time feels like tackling the insane monster known as ‘TextConstants’ we’d all breathe more easily.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Error 13: Illegal brain function. Process terminated.



Reply | Threaded
Open this post in threaded view
|

Re: Is prompting to make a pool dictionary useful?

Frank Shearar-3
On 7 January 2014 18:59, tim Rowledge <[hidden email]> wrote:
>
> On 07-01-2014, at 7:28 AM, Bert Freudenberg <[hidden email]> wrote:
>>> As a counterpoint, this method will only affect the creation of _new_
>>> pools: so should these _new_ pools be Dictionary instances, or
>>> SharedPools?
>>
>> Good point. Seems reasonable to encourage the use of SharedPools.
>
> Definitely. And if someone with some time feels like tackling the insane monster known as ‘TextConstants’ we’d all breathe more easily.

Hey cool, it doesn't even have keys of a homogenous type! (I have a
'Bitmap DejaVu Sans' key in mine.)

I'm going to add this to the list of things to do in 4.6!

frank