Creating a new PoolDictionary

Sorry, I'm sure this is super simple, but it's been causing me grief
for the past 2 days. I can't find an obvious way to create a new
PoolDictionary. I feel a bit like a dolt, but everything else has been
super simple to do. I double click the PoolDictionaries icon (in v6,
btw), select an OrderedCollection in the list, and on the right pane
click "New Item", type in the name of my pool, click ok, then get this
error:

---------------------------
Error evaluating expression...
---------------------------
Error: undeclared 'MyPoolConstants'



Try again?
---------------------------
Yes   No
---------------------------

I'm sure I'm just going about this the wrong way. Any suggestions?

Thanks!

Jeff M.

Jeff,

have a look at the class side of PoolDictionary class. You see one
method: named:

So for evaluating PoolDictionary named 'JKTest' just worked.

Regards,
Janos

Jeff,

have a look to the class side of PoolDictionary, you see only one
method.

For me the following worked:

In the New Item input field just wrote:
PoolDictionary named: 'JKTest'

Regards,
Janos

Janos wrote:
worked:

Well, not really. It just has not given any error messages...

Sorry,
Janos

Jeff,

> Sorry, I'm sure this is super simple, but it's been causing me grief
> for the past 2 days. I can't find an obvious way to create a new
> PoolDictionary. I feel a bit like a dolt, but everything else has been
> super simple to do. I double click the PoolDictionaries icon (in v6,
> btw), select an OrderedCollection in the list, and on the right pane
> click "New Item", type in the name of my pool, click ok, then get this
> error:

It is a bit "non intuitive" isn't it.

You need to note the subtitle on the page..." Evaluate".  What you have to
enter is a legal Smalltalk expression which Dolphin will _evaluate_ to
create a new item.  Try entering ...

PoolConstantsDictionary named: 'MyNewPool'

Note that when entering new Key/Value pairs into a pool that these are also
evaluations.  To enter a new key for example, you would enter 'ANewKey'


You might find it easier to create new pool dictionaries in a Workspace (or
package script).  Something like

Smalltalk at: 'MyNewPoolDictionary' put: PoolConstantsDictionary new.

(Smalltalk at: 'MyNewPoolDictionary' )
    at: 'Key1' put: 1;
    at: 'Key2' put: 2.


I ought to mention that one of my goodies is a PoolDictionaryBrowser that, I
think, is easier to use than the one in the base Dolphin image.

--
Ian

Use the Reply-To address to contact me (limited validity).
Mail sent to the From address is ignored.

Hmm, scrub the first bit.  You can use the Pool Dictionaries to inspect the
pools in the system and  to add/delete keys and values in an existing PCD.
You can't use it to add new pools though - they are added to the collection
in the Inspector but not actually added to the image.  It all makes sense I
suppose as the tool is just a bog standard Inspector...

So the easiest way is to add the PCD using a workspace and then edit it in
the Inspector

.... or use my goodie which _does_ add new PCDs to the image :-)

--
Ian

Use the Reply-To address to contact me (limited validity).
Mail sent to the From address is ignored.

Ian, et al.,

My apologies, Ian, if you receive a private e-mail.  I believe I clicked
the wrong option for replying.

I was having the same problem as Jeff, found a relevant post in DSDN,
and then on its advice installed your Pool Dictionary Browser package.
It's fantastic!  By the way, your goodies have enhanced our productivity
tremendously here.  Do you accept donations?

I've noticed that there is controversy in the literature about pool
dictionaries.  I'm wondering if perhaps constants belong in the class to
which they pertain or, better yet, in a separate constants class.  I
would be interested in your opinion.

Cheers,

Eric

been
> > super simple to do. I double click the PoolDictionaries icon (in v6,
> > btw), select an OrderedCollection in the list, and on the right pane
> > click "New Item", type in the name of my pool, click ok, then get
this
> > error:
>
> It is a bit "non intuitive" isn't it.
>
> You need to note the subtitle on the page..." Evaluate".  What you
have to
> enter is a legal Smalltalk expression which Dolphin will _evaluate_ to
> create a new item.  Try entering ...
>
> PoolConstantsDictionary named: 'MyNewPool'
>
> Note that when entering new Key/Value pairs into a pool that these are
> also
> evaluations.  To enter a new key for example, you would enter
'ANewKey'
>
>
> You might find it easier to create new pool dictionaries in a
Workspace that,
> I
> think, is easier to use than the one in the base Dolphin image.
>
> --
> Ian
>
> Use the Reply-To address to contact me (limited validity).
> Mail sent to the From address is ignored.

Jeff,

> I can't find an obvious way to create a new
> PoolDictionary.

Assuming the idea is to create a global PoolDictionary (so it can be added to
the #poolDictionaries: of a class -- the most typical use by far), then I do it
by evaluating code like:

    Smalltalk
        at: #MyConstants
        ifAbsentPut: [PoolConstantsDictionary new].

(Most, perhaps all, uses of pools are better satisfied by a
PoolConstantsDictionary than by a PoolDictionary.)

Then go the package browser and add the new global (MyConstants) to the list of
globals.  Use the context menu and "Add uncomitted...".

I put the pool creation code into a method, which also defnes all the
constants, rather than just using a workspace.  That way I can document the
constants, and can also modify or extend the creation code more easily.

    -- chris

Eric,

> I was having the same problem as Jeff, found a relevant post in DSDN,
> and then on its advice installed your Pool Dictionary Browser package.
> It's fantastic!  By the way, your goodies have enhanced our productivity
> tremendously here.  Do you accept donations?

No, I would feel obliged to do something about the documentation for the
goodies if I did :-)  Thanks for the kind words, and the thought, though.

> I've noticed that there is controversy in the literature about pool
> dictionaries.  I'm wondering if perhaps constants belong in the class to
> which they pertain or, better yet, in a separate constants class.  I
> would be interested in your opinion.

I tend to shy away from the more cerebral Smalltalk discussions (e.g. I've
still not really decided if accessors are a good or bad thing :-) ) so I'm
probably not the best person to ask.   I do tend to use them when I need to
define constants, I find them easier to use that ClassVariable constants and
I hadn't really thought about a separate constants class.  If I only need a
few constants defined then I am quite happy defining them as methods in the
class (either class or instance) where they are used but that obviously gets
unwieldy if you need a lot of them.

I would say PCDs are fine for large numbers of read-only constants but
shouldn't be used as a way of providing general purpose global variables.

--
Ian

Use the Reply-To address to contact me (limited validity).
Mail sent to the From address is ignored.

Chris,

> Then go the package browser and add the new global (MyConstants) to the
> list of
> globals.  Use the context menu and "Add uncomitted...".

FWIW.  I do the same for pools that are just used within the package that
the pool is added to but tend to avoid doing so for pools that are used
across a number of packages.  The only reason is that I can remember
confusing problems with circular dependencies caused by a number of inter
related packages that all referred to constants defined in the pool.  I
usually try to create/modify pools in the preinstall script of the package
that is most likely to be loaded first.

Probably just an indication of my poor package design though :-)

--
Ian

Use the Reply-To address to contact me (limited validity).
Mail sent to the From address is ignored.

Ian,

>Thanks for the kind words, and the thought, though.

You're most welcome.  I can understand the sticking point on the
documentation ;)

We, too, are wrestling with accessor methods.  The dilemma seems to be
common to all O-O languages, and there are definitely very strong pros
and cons here.

> I would say PCDs are fine for large numbers of read-only constants but
> shouldn't be used as a way of providing general purpose global
variables.

Many would seem to agree with you.  If one restricts usage of pool
dictionaries to constants, then perhaps there's no need for complex
encapsulation schemes.  And, after all, it is an elegant solution.

Thanks for the food for thought.

Cheers,

Eric
DSDN,
> > and then on its advice installed your Pool Dictionary Browser
package.
> > It's fantastic!  By the way, your goodies have enhanced our
productivity
> > tremendously here.  Do you accept donations?
>
> No, I would feel obliged to do something about the documentation for
the
> goodies if I did :-)  Thanks for the kind words, and the thought,
though.
>
> > I've noticed that there is controversy in the literature about pool
> > dictionaries.  I'm wondering if perhaps constants belong in the
class to
> > which they pertain or, better yet, in a separate constants class.  I
> > would be interested in your opinion.
>
> I tend to shy away from the more cerebral Smalltalk discussions (e.g.
I've
> still not really decided if accessors are a good or bad thing :-) ) so
I'm
> probably not the best person to ask.   I do tend to use them when I
need
> to
> define constants, I find them easier to use that ClassVariable
constants
> and
> I hadn't really thought about a separate constants class.  If I only
need
> a
> few constants defined then I am quite happy defining them as methods
in
> the
> class (either class or instance) where they are used but that
obviously
> gets
> unwieldy if you need a lot of them.
>
> I would say PCDs are fine for large numbers of read-only constants but
> shouldn't be used as a way of providing general purpose global
variables.
>
> --
> Ian
>
> Use the Reply-To address to contact me (limited validity).
> Mail sent to the From address is ignored.

Jeff M. wrote:
> Sorry, I'm sure this is super simple, but it's been causing me grief
> for the past 2 days. I can't find an obvious way to create a new
> PoolDictionary. I feel a bit like a dolt, but everything else has been
> super simple to do. I double click the PoolDictionaries icon (in v6,
> btw), select an OrderedCollection in the list, and on the right pane
> click "New Item", type in the name of my pool, click ok, then get this
> error:

Maybe this discussion is already over ... But when I need a new
PoolDictionary
I simply add it's intended name to the class template. Dolphin will give
you an
error message allowing you to have the PoolDictionary create on the fly.

Hope this helps.

Regards,

Udo

Ian,

> FWIW.  I do the same for pools that are just used within the package that
> the pool is added to but tend to avoid doing so for pools that are used
> across a number of packages.  The only reason is that I can remember
> confusing problems with circular dependencies caused by a number of inter
> related packages that all referred to constants defined in the pool.

That's not a problem I've had so far.  I suppose that when it does crop up,
I'll be forced to put the pool into a package by itself...

(I do have some absurdly small packages, there are even a couple on my website
which consist of a single loose method ;-)

BTW, I agree with you about when/whether to use PCDs.

    -- chris

Chris Uppal wrote:
> Assuming the idea is to create a global PoolDictionary (so it can be added to
> the #poolDictionaries: of a class -- the most typical use by far), then I do it
> by evaluating code like:
>
>     Smalltalk
>         at: #MyConstants
>         ifAbsentPut: [PoolConstantsDictionary new].
>

Chris,

Thanks. However, my next question would be, how do I then add this pool
to my package for use later by another image? I currently have created
all my OpenGL views, OpenGL libraries, etc, now I'd just like to have
all the constants in one localized place and add it to the rest of the
OpenGL package. Perhaps there is an alternative way to do this?

Thanks again to everyone!

Jeff M.

Jeff,

> Thanks. However, my next question would be, how do I then add this pool
> to my package for use later by another image?

Go to the intended package in the Package Browser.  Then use the context menu
in the package list to do "Add uncommited=>Global...".  Then select the name of
your pool dictionary from the popup list.  Alternatively, you can do something
very similar from the "Globals" tab of the PB.

It may be that Udo's method (which I didn't realise worked) will automaticaly
puts the pool into the same package as the initiating class.

BTW, a small warning.  If you ever want to delete a pool dictionary (or any
other global) remove it from the owning package /first/, or you'll end up with
a package that thinks it owns a non-existant global.  Since that breaks the PB
(understandably, since the package itself is broken), you won't be able to fix
it without diving in with inspectors...  (This may be more robust in D6, I
haven't checked.)

    -- chris

Jeff ,

> Thanks. However, my next question would be, how do I then add this pool
> to my package for use later by another image?

Chris' earlier reply is the best way for a set of constants to be shared
between a number of packages.  Basically ....

Create your pool and constants, either using a Dolphin workspace or saved in
a method (for documentation purposes).

Create a new package and add the pool  (IMHO, just the pool),  to the
package under the PackageBrowser's Global tab.

The constants package should then automatically be added as a prerequisite
to any other OpenGL package that contains a class which defines the pool in
a class definition.  For packages that don't you can add the globals package
as a manual prerequisite.

--
Ian

Use the Reply-To address to contact me (limited validity).
Mail sent to the From address is ignored.

"Chris Uppal" <[hidden email]> wrote in message
news:44840296$0$664$[hidden email]...
Are you sure about that Chris? I'm pretty sure that even in D5 that the
#globalRemoved: event was triggered, and that this got passed onto the
PackageManager, which keeps the packages in sync.

Regards

Blair

Thank you, everyone, for your help. I got it working now. Unintuitive
to say the least, but working none-the-less. :-)

Jeff M.

Blair

[me:]
I haven't retested it, I admit.  But I have rather clear memories of it taking
a fair bit of fiddling to unscramble the mess I got into when I /did/ try it
;-)

Of course, that was in a working image (or I would just have abandoned it
rather than fix it), so there may have been some contributing element there.

    -- chris