Multiple Returns, was Re: Common Lisp style macros inSmalltalk?

Chris Reuter cgreuter at calum.csclub.uwaterloo.ca
Wed Jan 19 05:20:45 UTC 2000


On Tue, Jan 18, 2000 at 08:10:11PM -0800, Dan Ingalls wrote:
> >On Tue, Jan 11, 2000, agree at carltonfields.com wrote:
> >[...]  
> >> The "strict" Smalltalkologist might observe (and it has been
> >> observed many times in these letters), that the proper
> >> methodological solution is that every such aggregating should have
> >> its own aggregating class.  Thus:
> >> 
> >> 	^ Foo with: expresion1 with: expression2 with: expression3.
> 
> Chris Reuter <cgreuter at calum.csclub.uwaterloo.ca> replied:
> >I would think that creating a new class just to return multiple
> >objects is overkill unless the class is also needed to do something
> >more.  What's the rationale for doing this rather than just returning
> >an array?
> 
> Just to keep this topic from dying, it would be fun (maybe it has
> been done already) to create a class of named tuples, where you
> could say,
> 
> 	^ Tuple voltage: 220 current: 7.5 startingTorque: 185
> 
> This would intercept messageNotUnderstood: on the first go-round,
> and create a simple subclass with three fields named, uh, 'voltage',
> 'current', and 'startingTorque', and with the appropriate creation
> and access methods.
> 
> It could all run about as fast as arrays, but be clearer, and not
> require any extra classes in the "library", as all such examples
> would be created on the fly as needed.

I like this idea but I'm a bit disturbed by the thought of
automatically creating subclasses.  In my mind, classes are code and
thus more precious than most of the other objects (which are usually
created by code anyway).  Creating new classes on the fly means that
suddenly, there is code that is not human-created.  (GUI builders that
generate C code frameworks also bother me for the same reason.)

What would be involved in adding the concept of disposable
classes--classes which don't show up in the browser, don't have source
code for their methods and go away when they're not needed?  If they
don't have names, they would go away when the last instance is
reclaimed.  If we use those, we can create classes that are clearly
not 

Does this make sense?  If not, my excuse is that it's past my bedtime.


			  --Chris





More information about the Squeak-dev mailing list