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 |
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 - |
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. |
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) |
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? >>> 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 |
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 - |
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? - Bert - smime.p7s (5K) Download Attachment |
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. |
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 |
Free forum by Nabble | Edit this page |