Peeping At The KeyHole

Chris Muller chris at
Tue May 2 18:01:22 UTC 2006

> 	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?

Yes, except you had to do a lot more work (i.e., rebuild the entire

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

Proper delegation of responsibility is absolutely good practice.  What
is poor software engineering practice is what a closed system like Java
forces developers into; creating "Utility" classes, usually just a
bunch of static methods (functions!) with a bunch of parameters just to
accomodate the need.

> 	My C# friends used to talk about data hiding, encapsulation, public,
> 	private, protected, internal, virtual, ... what a mouthful!

After twelve years with Smalltalk and six with Java, I have realized
this is all unnecessarily-complex computer jargon, none of it is really
concerned with addressing the problem domain.

What do your friends do when the statically declared access modifier is
not what they want; simple, they go and change it!  Its a rubber stamp
that clutters the program and does nothing to protect a running

> 	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?

All OO languages I know of allow it.  Note I do not consider Java an OO

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

Smalltalk is an open system, you always get the source code.  I would
not use a closed system.

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

Like any system, upgrading your software to work with new versions of
the system involves merging the code into the new system.  Thanks to
Monticello, merging is one of the eaiest things to do with Squeak.

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

Yes, it would require some extra work to rename the methods.  The
Refactoring functions make that rather trivial.

The key though, is to not "hog the namespace" with
inappropriately-generalized names in the first place.  In my
experience, method name collisions have never been a real problem.

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

Packages were a major step in the direction of modularizing Squeak.

I hope the Spoon project will lurch Squeak beyond all other systems in

It should be noted, so far, the only real benefit to extreme
modularisation (that I see) is reducing size of the image (which is
already much smaller than standard Java footprint anyway).  Unless
wanting to run on a PDA or specialized application, a small image isn't
such a big deal.

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

Don't know, I would never use such a rigid, closed system.


More information about the Squeak-dev mailing list