<div class="gmail_quote">On Tue, Mar 25, 2008 at 5:44 PM, Ramon Leon <<a href="mailto:ramon.leon@allresnet.com">ramon.leon@allresnet.com</a>> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Classes are objects too, just because most classes build instances doesn't<br>
mean they all have to. You might not want a class doing both, but I see no<br>
reason it can't do one *or* the other. Serving as a singleton works well<br>
when it's needed and keeps code simple. Saying a class should only create<br>
instances seems a rather arbitrary restriction to place upon your designs.</blockquote><div> <br></div><div>As a beginner who is finally starting to do some useful [Smalltalk] work in a Healthcare organization, I am finding this conversation very interesting because I write a lot of "utility" code...mostly data "pre-processing" before it goes to the Warehouse, the Reporting engine, or to files to go out the door for required reporting to other organizations. </div>
<div><br class="webkit-block-placeholder"></div><div>Should I consider something more than just "XXFileProcessor file: aFile" if it will only ever run on one file that shows up in a directory once a day and the whole point is that there is only ONE processor?</div>
<div><br class="webkit-block-placeholder"></div><div>Just interested, because in such "utility" cases I end up with all my helper methods on the class side and wonder to myself, "is this wrong?" because it feels very similar to writing subroutines in any other language...<br>
</div><div><br class="webkit-block-placeholder"></div><div>On that note, isn't that sort of all traits really are? A subroutine not attached to any particular object? But with no access to object data short of resorting to things like self classPool at: #Var, which I suppose defeats the point, but darn it, I keep running into situations where multiple inheritence would be great! </div>
<div><br class="webkit-block-placeholder"></div><div>Rob Rothwell</div></div>