[Q] Fiddling with system innards, was [Q] Newbie - Multiple Return Values

Cees de Groot cg at cdegroot.com
Thu May 1 17:09:11 UTC 2003


On Thu, 2003-05-01 at 18:53, Ingo Hohmann wrote:
> where I come from fiddling with the system innards is supposed to be a 
> 'black art'.
> 
In Smalltalk, it isn't supposed to be a black art. So get used to that.

> 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.
> 
However, this is not 'fiddling with system innards'. Everything you do
is logged in a changeset, and you can thus see what you changed, undo
your changes, file them out to a text file and throw them at a version
repository, etcetera. Yes, programming in an image-based Smalltalk is
different from programming most other languages, but don't let that stop
you from writing good code.

> _That's_ why I am reluctant to create new classes.
> 
And that's completely the wrong reason :-)

> 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?
> 
Not clean at all, you'll create parallel hierarchies that serve no-one
except the vendors of expensive parallel-hierarchy-tracking tools (also
called 'UML modellers' or 'CASE tools' ;-)).

First, you need to think about what the best place is for a method. When
you found it, you put it there. Of course, when you put it in an
existing class you'll take some extra care to make the thing either
completely non-obvious (give it a name prefixed with your initials so
that no-one else is likely to make the same 'class extension') or
completely obvious (say the method 'isSymbol', which would return
'false' in its implementation in the Object class and 'true' in its
implementation in the Symbol class) so that if someone else makes a
class extension with the same name, it will have the same behavior so it
won't collide with your version. But there's no a priori reason you
shouldn't put your method in String if all signs are that it belongs in
String.

Smalltalk has tools to keep these class extensions apart from the 'base
methods'. The default method in Squeak is that all your code is kept in
a changeset; a changeset basically is a sort of transaction log of your
changes, and does not care when you define a method whether the class
was 'yours' or 'someone else's'. A newer method in Squeak is a DVS
package, which relies on some naming conventions in the extended classes
to make them part of the package you want them to be in. On both topics
you'll find abundant information on the Squeak Swiki.

Regards,

Cees
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030501/e1097289/attachment.pgp


More information about the Squeak-dev mailing list