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