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

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