Hi Cees,

Cees de Groot wrote:
<..>
> Really, encapsulating the result in a class is much nicer, especially
> because you can then start converting 'tell' methods into 'ask' methods
> (don't "give me foo" but "please do bar with whatever you represent").
> There's about zero overhead (probably exactly zero - whether you
> construct an Array instance with two or three members or a FooResult
> instance with two or three instance vars does not matter).
<..>

I'm quite willing to sacrifice some performance for clarity (otherwise 
I'd be using assembler, or even -uuuugh- C), but

where I come from fiddling with the system innards is supposed to be a 
'black art'.

Actually, my problem is that, everything I do is in the image to stay - 
that's quite a difference to writing a script that changes whatever it 
wants to in the system, when it does not interfere in any way with other 
scripts/programs.

_That's_ why I am reluctant to create new classes.

On a related note, assume I would like to do something with strings/any 
standard class, that the current implementation does not allow. What is 
the way to go then?

Should I extend the String class in the system?
Create a subclass of String that understands my additional messages?
Create a StringHelper which understands #myMessage: aString?

The latter seems to be the cleanest to me, what do you think?


Kind regards,

Ingo