Hey Bob,
I will have to think about this for awhile. I like how values in a pool dictionary look in code. But I take your point about being able to browse methods and group them in categories (I would have to get Alex to work on the categories and what goes in them). Bert seems to like pool but also thought instance methods would be good. Someone also said they would prefer class side methods. I could go with the pool dictionary I have (I fixed the initialize as you suggested, thanks) and add class methods to create the instance/class methods and let people run them if they like.
I will think about it and I'm still open to suggestions.
Lou
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.
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.
----------------------------------------------------------- Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon mailto:Lou@Keystone-Software.com http://www.Keystone-Software.com