How to use pool dictionaries in a workspace?

>On 3/5/13 1:56 PM, Louis LaBrunda wrote:
>> Hi,
>>
>> When I want to use values defined in a pool dictionary in VA Smalltalk, I
>> put the following lines at the top of the workspace (I often save
>> workspaces for repeat use):
>>
>> "
>> EtWindow defaultEvaluationPools: (EtWindow defaultEvaluationPools asSet
>> addAll: #(#PoolDictionaryName)) asArray.
>> EtWindow defaultEvaluationPools: nil.
>> "
>>
>> If I execute the first line (not counting the comment " line and not
>> wrapped) The named pool dictionary is available to the workspace.  I can
>> test code as if the pool dictionary were specified for the class and I was
>> writing a method.  This way when I'm happy with the code, I can just copy
>> it to a method and use it as is.  The second line puts things back the way
>> it was.
>>
>> I would love to be able to do this with Squeak.  Does anyone have any idea
>> how to do this with Squeak?  Or point me in the right direction?
>>
>> Lou
>> -----------------------------------------------------------
>> Louis LaBrunda
>> Keystone Software Corp.
>> SkypeMe callto://PhotonDemon
>> mailto:[hidden email] http://www.Keystone-Software.com
>>
>>
>>

>
> Thanks again for the help.
>
> Lou
>
>> On 3/5/13 1:56 PM, Louis LaBrunda wrote:
>>> Hi,
>>>
>>> When I want to use values defined in a pool dictionary in VA Smalltalk, I
>>> put the following lines at the top of the workspace (I often save
>>> workspaces for repeat use):
>>>
>>> "
>>> EtWindow defaultEvaluationPools: (EtWindow defaultEvaluationPools asSet
>>> addAll: #(#PoolDictionaryName)) asArray.
>>> EtWindow defaultEvaluationPools: nil.
>>> "
>>>
>>> If I execute the first line (not counting the comment " line and not
>>> wrapped) The named pool dictionary is available to the workspace.  I can
>>> test code as if the pool dictionary were specified for the class and I was
>>> writing a method.  This way when I'm happy with the code, I can just copy
>>> it to a method and use it as is.  The second line puts things back the way
>>> it was.
>>>
>>> I would love to be able to do this with Squeak.  Does anyone have any idea
>>> how to do this with Squeak?  Or point me in the right direction?
>>>
>>> Lou
>>> -----------------------------------------------------------
>>> Louis LaBrunda
>>> Keystone Software Corp.
>>> SkypeMe callto://PhotonDemon
>>> mailto:[hidden email] http://www.Keystone-Software.com
>>>
>>>
>>>
> -----------------------------------------------------------
> Louis LaBrunda
> Keystone Software Corp.
> SkypeMe callto://PhotonDemon
> mailto:[hidden email] http://www.Keystone-Software.com
>
>
>

>On 2013-03-05, at 20:51, Louis LaBrunda <[hidden email]> wrote:
>
>> Hi Bob,
>>
>>> Have you tried
>>> Workspace addLookupPool: MyPool?
>>
>> Thanks, that works great although the #removeLookupPool: doesn't seem to
>> turn it off but I'm not sure I care.
>
>The values you use are copied into the Workspace instance's own bindings.
>
>Maybe that's what you're seeing?
>
>- Bert -
>
>
>

>>> Although I wonder why one would go to the trouble. Why not just put the
>>> code in a method that can reference the pool normally?
>> One could say that about anything you might want to play with in a
>> workspace.
>I'm not opposed to workspaces, but when you are spending energy to make
>a workspace do what a class & method will already provide, seems like
>re-inventing the wheel.
>> As I said, I often work up code in a workspace and then copy it
>> to a method when I'm happy with it.  If I can't use pool references in the
>> workspace, I then have to change things when I want to make a real method.
>I don't understand this part. If you put it in a method from the start,
>then when it works, you're done.

>>> One could say that about anything you might want to play with in a
>>> workspace.
>> I'm not opposed to workspaces, but when you are spending energy to make
>> a workspace do what a class & method will already provide, seems like
>> re-inventing the wheel.
>>> As I said, I often work up code in a workspace and then copy it
>>> to a method when I'm happy with it.  If I can't use pool references in the
>>> workspace, I then have to change things when I want to make a real method.
>> I don't understand this part. If you put it in a method from the start,
>> then when it works, you're done.
>
> I often have to play with objects (not so much in Squeak but in my VA
> Smalltalk work) that would cause problems if I instantiated them in order
> to test a new method.  Sometimes I can't even test them on my computer but
> have to test them in production (they want to talk to some host that I
> don't have access to).  If I instantiate them they start doing things I
> don't want them to do and they interfere with the testing.  So, I can and
> must do a lot in a workspace.  It may not be ideal but that's life.

>Hey Lou
>Am 05.03.2013 um 22:18 schrieb Louis LaBrunda <[hidden email]>:
>
>>>> One could say that about anything you might want to play with in a
>>>> workspace.
>>> I'm not opposed to workspaces, but when you are spending energy to make
>>> a workspace do what a class & method will already provide, seems like
>>> re-inventing the wheel.
>>>> As I said, I often work up code in a workspace and then copy it
>>>> to a method when I'm happy with it.  If I can't use pool references in the
>>>> workspace, I then have to change things when I want to make a real method.
>>> I don't understand this part. If you put it in a method from the start,
>>> then when it works, you're done.
>>
>> I often have to play with objects (not so much in Squeak but in my VA
>> Smalltalk work) that would cause problems if I instantiated them in order
>> to test a new method.  Sometimes I can't even test them on my computer but
>> have to test them in production (they want to talk to some host that I
>> don't have access to).  If I instantiate them they start doing things I
>> don't want them to do and they interfere with the testing.  So, I can and
>> must do a lot in a workspace.  It may not be ideal but that's life.
>
>
>I can relate there ;)
>
>I am curious why you want to use Pool Dictionaries in the first place.
>Not that I question them, but I have up until now never hat the necessity
>to use them, so I would be delighted to see why they are useful :)
>
>Best
> -Tobias

> On 2013-03-06, at 10:36, Tobias Pape <[hidden email]> wrote:
>
>> I am curious why you want to use Pool Dictionaries in the first place.
>> Not that I question them, but I have up until now never hat the necessity
>> to use them, so I would be delighted to see why they are useful :)
>>
>> Best
>> -Tobias
>
>
> They're pretty useful for constants you want to share across class hierarchies.
>
> E.g. all the OpenGL constants are in a pool dict. Makes for simpler-to-read code.
>
> Lou uses it for the Minecraft ids. Compare:
>
> mc blockAt: {x. y. z} put: #(35 "wool" 10 "purple)
>
> vs
>
> mc blockAt: {x. y. z} put: PurpleWool
>
> vs
>
> mc blockAt: {x. y. z} put: MinecraftBlock purpleWool
>
> Any better idea?