[Q] Fiddling with system innards, was [Q] Newbie - MultipleReturn
Values
Jimmie Houchin
jhouchin at texoma.net
Thu May 8 20:37:37 UTC 2003
Cees de Groot wrote:
> 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.
>
[snip]
>
>>_That's_ why I am reluctant to create new classes.
>
> And that's completely the wrong reason :-)
[snip]
>
> 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
Here is a situation I had last week. While exploring the MP3 ID3 code I
was using the FileList2 modalFileSelector method. It wasn't what I
needed because it returned the selected object not the filePath that the
ID3 code wanted. So brazenly, I went in and added a couple methods to
FileList2 which only changed 1 line in a couple of existing methods:
modalFileSelector to>> modalFilePathSelector which depended on:
getSelectedFile to>> getSelectedFilePath.
Then latter I had similar needs for directories and I did similarly.
Should I make my methods above into:
FileList2 jlhModalFilePathSelector (class)
jlhGetSelectedFilePath (instance)
?
Naively, I think these might be handy for others in the community. But,
I have no confidence in offering such. So I didn't. I could, and they
could be easily reviewed. When I have such boldness I guess such would
be an [ENH], correct?
I guess I need to create a changeset for those methods if I want to
share them with myself for the many different images I have going. Is
there better ways for me to share my own code? It seems easy when its in
my own categories, but not as easy when I mix it up in other categories
and classes. Am I missing something?
Thanks for any wisdom and insight.
Jimmie Houchin
More information about the Squeak-dev
mailing list
|