Please feel free to remove: Re: Re: Re: Re: Re: Re: Re: Re: Re:

 

Ron

 

From: squeak-dev-bounces at lists.squeakfoundation.org
[mailto:squeak-dev-bounces at lists.squeakfoundation.org] On Behalf Of Bob
Arning
Sent: Wednesday, March 06, 2013 10:06 AM
To: squeak-dev at lists.squeakfoundation.org
Subject: Re: [squeak-dev] Re: Re: Re: Re: Re: Re: Re: Re: Re: [ANN]
Minecraft Bindings - Minecraft.zip (0/1)

 

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.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130306/d2037199/attachment-0001.htm