On 2013-03-06, at 16:34, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
2013/3/6 Bob Arning arning315@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.