Peeping At The KeyHole

SmallSqueak smallsqueak at
Tue May 2 07:02:03 UTC 2006

Ralph Johnson wrote:

> On 5/1/06, SmallSqueak <smallsqueak at> wrote: 
> About adding methods to existing classes ....

> >   Is this a rule, that I have to add methods to existing classes? 
> >   Would you please explain why it is a good thing.
> You don't have to, but you can.  You can't do it in C++ or Java.  
> It is a good thing because sometimes when you want to extend a system, 
> you want old objects to interact well with new objects, and it is easier 
> if you can add methods to old objects.  And I really mean "old objects" 
> and not just "old classes", though of course that is included. 

	In C++ and its derivatives if I have the source for the whole
	can I just add methods to any class I want to then rebuild the whole


	Would the effect be the same as what you are saying for Smalltalk?

	I can't really see that this is good software engineering practice.

	My C# friends used to talk about data hiding, encapsulation, public,

	private, protected, internal, virtual, ... what a mouthful!

	Is there a name for this technique of adding methods to existing
	Is there some reference on this technique? I want to do some
	and show off to them ;-)

	Just for curiosity reason, are there any other OOP languages that
	this practice?

> Suppose you want to add a new kind of tool to the system, one that helps
> debug objects.  You want to be able to send a message "debug" to every
> You can add a default "debug" method to class Object and override that
> in classes that need a different implementation.  

	If you don't have access to the source code of Object, can you build

	this debugger?

	When it's time to upgrade/update the Smalltalk system, do you have
	to go to each of these classes that you modified to repeat the whole

	Would it be cumbersome if the new version of Smalltalk has the
	with the same name as the ones you added?

	BTW, would this technique help or hinder the efforts to make Squeak 
	modular? The whole Squeak community have been struggling for several
	years to modularize Squeak but it looks like no one really knows

> >   What if the authors of the existing classes don't want
> >   anything added to their classes?
> When you publish the source code to something, it is a gift to the world. 

> The world can do what it wants with it.  If you think the world is better
> without adding methods to a particular class, by all means write a comment

> to that effect.  
> But you might be wrong, and the world will show you by adding methods

	That's true. 
	The spirit of my question was that what if for one or another
	you cannot change existing classes, what would you do to implement
	your debugger.

> > > Just focus on Collection classes and numbers.

> >   I like to ignore these as well.
> I think this is a mistake.  The collection classes are very important.  
> They are also great examples of well-designed Smalltalk classes.

	Please don't get me wrong. I certainly will have a good look
	at the collection classes after fully understood the KeyHole 

	To me this is the only way I can ever make any progress in 
	learning Squeak. I call it SmallLearn ;-)

	The hard part now is how can I identify the KeyHole classes
	and satisfy myself that they are truly smallest cluster of 
	independent classes, using various browsers available for Squeak.




More information about the Squeak-dev mailing list