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@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)--
squeak-dev@lists.squeakfoundation.org