On Tue, 4 Nov 2003 15:11:14 +0100, Peter van Rooijen 
<peter at vanrooijen.com> wrote:

> From: "Brent Pinkney" <brent.pinkney at aircom.co.za>
>> I still strongly believe that the Smalltalk tradition of not naming
>> classes with type information should be observed.
>>
>> e.g. ClassRenameEvent should just be ClassRename.
>
> I agree that a class name should not end with a type/category suffix, but
> that doesn't mean the type/category should be lost. Indeed, it must be 
> kept.
> The natural mechanism for that is the namespace.
>
> After all, we have to be able to make the distinction between
> Event.ClassRename and Refactoring.ClassRename, don't we?
>
> In the absence of syntax for namespaces in names, you have no choice 
> except
> to make the disctinction in the full name itself. For this prefixes are
> almost always better than suffixes.
>
I must differ.

I hope I can use this thread to convince all contributors of how important 
it is how the code looks to maintaining the eloquence, tersness and power 
of Smalltalk. Indeed Smalltalk is (apparently) so named becuase its 
creators were so frustrated with the arcaness of programming languages 
that one quipped that merely raising the bar to the level of small-talk 
would be a huge improvement.

That is to say the aesthetic aspect is as important as the mechanics of 
blocks, object, meta-classes, etc. Compare the average Smalltalk snippet 
to its Perl or Ruby evuivalent.

One aspect of this is consistency: There is already consensus shown by the 
Prefix Registry that although the name collision issue is well understood, 
only packages have prefixes; classes in the base image do not have 
prefixes or suffixes.

You are arguing that we should change the name of MessageNotUnderstood to 
MessageNotUnderstoodException or ExceptionMessageNotUnderstood. Surely by 
extension we chould change Integer to ClassInteger ans String to 
ClassString ?

Secondly, from an aeththesic perspective there is something elegant and 
colloqiual about

	[ x /y ] on: DivideByZero do: [ self inform: 'oops' ]

that is lost if we decend into _CODE_ **

	[ x /y ] on: ExceptionDivideByZero do: [ self inform: 'oops' ]

Read it aloud to convince yourself.

Pseudo-coding in a similar vein:

	Smalltalk when #renameClass send: #updateChangeSet to: Changeset current.

	ClassBuilder>>#rename: aClass to: aNewClassName
		...con
		...
		self triggerEvent: #renameClass
			with: (RenameClass class: aClass newName: aNewClassName).

There is something very terse and readable about this. Indeed the 
#triggerEvent: method lets the reader know that this is an event. In 
addition the receiver of the event has the reflective facilities, should 
the exact implementation type be important: The eye is not badgered by the 
irrelevant.

The argument that the above is fine and well for executing code, but 
inadequate for reading code and following the chain of events is weak: 
Smalltalk methods are short and the environment is superb for browsing 
sendors and implementors.

In short, this naming classes with their implementation type is a carry 
over from other programming languages and it merely a form of Hungarian 
Notation which has no place in Smalltalk.

Regards

Brent