Peeping At The KeyHole

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


Ralph Johnson wrote:

> On 5/1/06, SmallSqueak <smallsqueak at rogers.com> 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
system, 
	can I just add methods to any class I want to then rebuild the whole

	system? 

	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
classes?
	Is there some reference on this technique? I want to do some
googling
	and show off to them ;-)

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

> Suppose you want to add a new kind of tool to the system, one that helps
you 
> debug objects.  You want to be able to send a message "debug" to every
object.  
> You can add a default "debug" method to class Object and override that
method 
> 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
	procedure. 

	Would it be cumbersome if the new version of Smalltalk has the
methods 
	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
how.


> >   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
off 
> 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
anyway. 

	That's true. 
	
	The spirit of my question was that what if for one or another
reason,
	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 
	classes. 

	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.


	Cheers,

	SmallSqueak

 




More information about the Squeak-dev mailing list