kpgrant at mindspring.com wrote:
> 
> Is there any elegant method for handling occasions when you
> wish a method to return multiple objects?  I'm writing a
> method that will return a set and a dictionary to the
> caller.  I can't reasonably break up the method into two
> methods (one for each kind of data), and the contents of
> the set and dictionary are unrelated enough that it seems
> silly to make a whole new class of object containing nothing
> but pointers to each.  The only thing that occurs to me is
> something like:
> 
> ^((OrderedCollection new) add: myDictionary add: mySet)
> 
> and then disassemble the thing on the receiving side.  I'm
> not really crazy about this though.

One thing that you could do is have the method take an empty
set and empty dictionary as arguments, and instead of returning
them, it could add the items to them.  That way the calling
method already has them in variables (one would assume).

My concern though is that I don't really understand the context.
If you list the design issue you're trying to resolve here
(why do you have to create two unrelated collections in the same
method?)  there might be a better solution in the specific.

Problems like this are often a big sign saying "your design isn't
right" cause it's fighting you.  Not always.  But often.

-- 
Dana Lynne Goldblatt Anthony
Internet Publications Technology at SAS Institute
World Headquarters Cary, NC, USA