[squeak-dev] Shared Pools (was: [ANN] Minecraft Bindings - Minecraft.zip (0/1))

Bert Freudenberg bert at freudenbergs.de
Wed Mar 6 15:42:12 UTC 2013


On 2013-03-06, at 16:34, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> wrote:

> 2013/3/6 Bob Arning <arning315 at comcast.net>:
>> The pool approach is probably good, but I'm always a little leery of things
>> stored in different ways and places. Since the system browser, optimized for
>> looking at classes and methods, is the primary tool for most of us, I tend
>> to prefer ways to work within that context. Defining pool variables and then
>> defining methods to return those variables does seem a bit much, but what
>> about dispensing with the pool variables and auto-generating methods like:
>> 
>> brownWool
>> 
>>    ^#(35 12)
>> 
>> These methods could be grouped in categories to facilitate browsing for
>> interesting textures/objects/whatchamacallums. For most of us browsing for
>> senders is a bit more natural than browsing for references to pool
>> variables. FWIW.
>> 
> 
> But in a trunk image nowadays, cmd+shift+N should catch the references
> to ivars/class var/pool var as easily as cmd+n would catch senders,
> right?
> 
> Nicolas

Even a simple cmd-n does find them, e.g. BlueButtonBit.

- Bert -

>> Cheers,
>> Bob
>> 
>> 
>> 
>> On 3/6/13 9:43 AM, Louis LaBrunda wrote:
>> 
>> Yes it is.  But at the time I thought (my mistake) Bert wanted/suggested
>> that I create instance side messages to his Minecraft class.  That would
>> require it having the pool dictionary defined before the methods could be
>> added and I kind of wanted it to be all automatic.  As it turns out Bert is
>> happy with just the pool dictionary and people can add/use it wherever they
>> like.


More information about the Squeak-dev mailing list