<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META content="MSHTML 5.00.2614.3500" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV>&nbsp;</DIV>
<DIV>Ingo Hohmann &lt;<A href="mailto:ingo@2b1.de">ingo@2b1.de</A>&gt; asked 
about ways to represent</DIV>
<DIV>multiply return values and he got some interesting answers.</DIV>
<DIV>&nbsp;</DIV>
<DIV>I agree with Cees that code like</DIV>
<DIV>&nbsp;</DIV>
<DIV>result := foo doSomething.<BR>(bar := result at: 1) &gt; 0<BR>&nbsp;&nbsp; 
ifTrue: [self error: (result at: 3)]<BR>&nbsp;&nbsp; ifFalse: [^result at: 
2]<BR></DIV>
<DIV>is a candidate for easy improvements. Yes, it is of course possible to use 
an Array and it works, but </DIV>
<DIV>&nbsp;</DIV>
<UL>
  <LI>when you use a class - say: MyStructuredMessage - you can use the option 
  "class refs" of the browser to find all methods that reference the class. You 
  can of course also ask for all references to class Array, but in our newest 
  standard image the browser will disappoint you with almost 2.000 methods. It 
  is then your task to find out what all these methods do and which are the ones 
  that you are looking for. 
  <LI>when you use methods with specific names, you can search for both the 
  senders and the implementors. This is often very helpful. You can of course 
  search for all senders of method 'at:' but you have to know that this method 
  is defined in the instance protocol of Object (and inherited by Array) and you 
  will get more the 3.500 senders (in out standard image) 
  <LI>as Cees pointed out, method names are much more informative than array 
  indices. Users of your code will find it easier to read&nbsp; 'result payload' 
  'result status' 'result checksum'&nbsp; than (result at: 1), (result at: 
  2)&nbsp; and so on. You should also not underestimate the possibility that you 
  want to change the format of you structured return value for some reason. 
  Consider the following situation: 
  <UL>
    <LI>You have a value&nbsp; <STRONG>Array with: payload with: checksum with: 
    state</STRONG> 
    <LI>Somewhere in your code you access the state with (array at: 3), in other 
    places you write&nbsp; (array last) 
    <LI>You did not anticipate it, but for some reason you have to add a fourth 
    data field to your value. To keep the expression (array last) correct, you 
    cannot add the new field after the last one, and to keep the expression 
    (array at: 3) correct, you have to add the new field after the third field 
    which is the last one. You have now all reason to rethink your use of an 
    array.</LI></UL></LI></UL>
<DIV>There is a related problem and I want to explain that too, because it is 
one of the most costly mistakes that I ever made (in Smalltalk, not in 
life)</DIV>
<DIV>&nbsp;</DIV>
<DIV>I had a lot of cooperating classes and in the instance protocol of all 
these classes I had methods with identical names (I wanted to use polymorphism 
and that was ok). Initially these methods had a small number of parameters, but 
later I had repeatedly to add additional parameters. Every time I needed a new 
parameter, I added that new parameter to all these methods and than I updated 
all senders. Finally I removed&nbsp;all the obsoleted methods. I can only regret 
my foolishness, but it took me some time to understand that I failed to define a 
class for all my parameters. (I was even not smart enough to use an array!) 
Now&nbsp;that I have understood that, the introduction of an additional 
parameter is very easy. I add an instance variable and access methods to the 
class that keeps all the parameters and I have to rework only the methods that 
have to access the additional parameter.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Given this experience, I think now that is is not best practice to ask "Do 
I really need a class?". It is - in my opinion - much better to ask: "What 
problems will I&nbsp;incur when I do not define a class?"</DIV>
<DIV>&nbsp;</DIV>
<DIV>By the way, I agree that the use of exception is not always a good 
solution. Use of exceptions becomes increasingly difficult when you have to 
handle additional data elements (the equivalent of adding instance variables to 
a class)</DIV>
<DIV>&nbsp;</DIV>
<DIV>Just my 2 eurocents,</DIV>
<DIV>Boris</DIV></BODY></HTML>