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

Daniel Vainsencher danielv at netvision.net.il
Fri May 2 00:18:47 UTC 2003


Building on what Cees said - the methods you will write initially will
probably be geared to your specific application
(String>>findComicMarker). The next step is to realize there's a general
part to that method (some kind of searching in strings), and an
application specific part, which String really should have no knowledge
of (the pattern to be found). Then you'll make it into
String>>findMarker: which is called from 
ComicParser>>findMarker
	content findMarker: self marker

When you've cut down the functionality related to String to it's most
general form, you're quite likely to come up with something that is
generally useful, and then it will either -
A. Be a useful or at least reasonable addition to the base class
library, and you might want to submit it to the list members' scrutiny.
B. Already be implemented. This is very very common - the basic classes
are very very rich in functionality. This is not a waste of time, it's
an opportunity to simplify.

I differ with Cees comments on one point - changesets are a very easy
way to start playing around (they are maintained automatically, and can
be edited easily), but they stink as a way to manage core over time.
This is especially if you have class extensions. If your application is
more than a few classes, use DVS or something like it.

Daniel

Cees de Groot <cg at cdegroot.com> wrote:
> 
> --Boundary_(ID_wFgDtfzrwXRzid8qV2dN5w)
> Content-type: multipart/signed; boundary="=-zkE9eJEpApU0f0bzcQS+";
>  protocol="application/pgp-signature"; micalg=pgp-sha1
> 
> 
> --=-zkE9eJEpApU0f0bzcQS+
> Content-Type: text/plain
> Content-Transfer-Encoding: quoted-printable
> 
> 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=20
> > 'black art'.
> >=20
> 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 -=20
> > that's quite a difference to writing a script that changes whatever it=20
> > wants to in the system, when it does not interfere in any way with other=20
> > scripts/programs.
> >=20
> 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.
> >=20
> 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?
> >=20
> > The latter seems to be the cleanest to me, what do you think?
> >=20
> 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
> 
> --=-zkE9eJEpApU0f0bzcQS+
> Content-Type: application/pgp-signature; name=signature.asc
> Content-Description: This is a digitally signed message part
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (GNU/Linux)
> 
> iD8DBQA+sVS28wOTf+CYnosRAuLyAJ9fpPG+5lmB1FwxoGswlxnwpNSPmgCfd2Z3
> 2CFsk9gy8EhBEiCV8VRY4cU=
> =WKU2
> -----END PGP SIGNATURE-----
> 
> --=-zkE9eJEpApU0f0bzcQS+--
> 
> 
> --Boundary_(ID_wFgDtfzrwXRzid8qV2dN5w)
> MIME-version: 1.0
> Content-type: text/plain; charset=us-ascii
> Content-transfer-encoding: 7BIT
> 
> 
> 
> --Boundary_(ID_wFgDtfzrwXRzid8qV2dN5w)--



More information about the Squeak-dev mailing list