That was indeed my motivation. The whole problem with the name is that 
the names of the events by themselves are too short (similarly like the 
example Doug gives with the BorderedMorph). In my case the events would 
be called Added, Renamed, Removed, DoIt, Resupered, Commented, ... : to 
me this was not very clear. Would I have been able to add some more 
context, I would not have needed a suffix. I mean, suppose that I would 
have needed separate events for renaming classes, renaming methods, 
renaming protocols, ... Then I would have simply called this 
ClassRenamed etc., without adding a prefix nor suffix. But just Renamed 
sounded weird.


Note that hungarian suffix notation is used to make the type visible in 
the name. It is a quite useful naming convention when you working with 
a group of people in a statically typed languages. Hence I fully agree 
that it has no place in Smalltalk.

Would it merely be the case that I wanted to differentiate between my 
classes and other system classes I would have used a prefix, and not a 
suffix. In that case I would have called my classes 
NotificationSuperChanged or something, like all of my old VW code was 
prefixed with SOUL, LPS, MakigKeys, Classification, ... But while very 
useful it does tend to read much worse (like in VA, where I really hate 
their names even though I understand why  did it). So not using 
prefixes for system classes was not a bad suggestion that I really 
preferred over VA's solution of prefixing everything. But of course, 
with respect to eloquency, namespaces are the way to go.

On Tuesday, Nov 4, 2003, at 19:51 Europe/Zurich, Doug Way wrote:

>
> Brent Pinkney wrote:
>
>> ...
>> It is precicely because Roel's System Change events are _probably_ 
>> going to be included in the base image, that we thrash out and firmly 
>> establish the naming convention we would like to see observed in 
>> Squeak.
>>
>> As I have explained and illustrated, and you and others previously 
>> concurred, the tradition is to avoid prefixes or suffixes.
>>
>> However, disambiguation of more optional classes is a separate 
>> unrelated issue and for that reason there already exists the Prefix 
>> Registry page on the Swiki reserve such prefixes.
>>
>> As illustrated, one of the de-facto standards is to avoid the 
>> Hungrian convention of including implementation type in the name. So 
>> even if I have a new Event subclass to capture the ocurrence of a 
>> flower blossoming in package BloemStuff, its name would be 
>> BloemFlowerBlossom and not BloemFlowerBlossomEvent or 
>> BloemEventFlowerBlossom.
>
>
> I agree 100% that we don't need to have prefixes and suffixes in 
> base-image class names for namespace reasons.
>
> However, some suffixes are arguably useful as simply a more 
> descriptive class name, even if they might be a bit redundant with 
> regard to a superclass name.  For example, BorderedMorph is a subclass 
> of Morph.  You could argue that it should just be called Bordered, but 
> that seems less readable to me.  I think of it as a "bordered morph", 
> not just a "bordered".  (A noun suffix (e.g. "Morph") is especially 
> helpful if the class would otherwise not be a noun (e.g. "Bordered").)
>
> So in that sense, perhaps Roel's naming of classes with an "Event" 
> suffix is perfectly fine.
>
> - Doug
>
>
>
Roel Wuyts                                                              
   DeComp
roel.wuyts at ulb.ac.be                               Université Libre de 
Bruxelles
http://homepages.ulb.ac.be/~rowuyts/                                    
Belgique
Board Member of the European Smalltalk User Group: www.esug.org