[MCP] [Q] Methods not used-Keep Them!

Michael Fremont mike at zorch.com
Fri Feb 14 22:28:37 UTC 2003

The XP point of view *is* to remove them if you don't need them soon, 
I agree.  But the XP point of view applies to a closed, controlled 
project, not to a programming system that outside people you may have 
no contact with also use.

We can't tell that a method isn't being used just because it's not 
used in the image.  Let me give an example.  Last year some code in 
the image was removed in favor of an updated version that didn't need 
the old code.  But there was external code, a goodie, that did.  That 
goodie broke when I updated the system.  Since I didn't write the 
goodie and was relatively new to Squeak, it took me hours and some 
lost hair to understand what happened, to find an old image, and to 
add back in the removed code.

I *love* the idea of cleaning up the system, and I laud everyone for 
working towards that.  I *love* that the question was asked, 'is 
anyone using this?'.  But people not actively reading the list can't 
answer the question, and their systems are going to break if we 
remove bits.

If an argument can be made that *substantial* improvements can be made 
by removing methods, perhaps the cost is worth it.  If the only 
benefit is to reduce the number of methods, but not the complexity of 
the system, then, my two cents, it's not worth it.



On Friday 14 February 2003 12:05 am, Hannes Hirzel wrote:
> "Doug Clapp" <dclapp at qwest.net> wrote:
> > Yes!  I'm in interested in ALL those methods!
> A conservative approach!
> > Why would you want to remove them??
> >
> > Just because they *aren't* used doesn't mean that
> > they have no use and no value!
> Yes, but that's not the point here.
> > Jeesh...
> >
> > doug
> Well from an XP point of view it is better to remove them even if
> you need them later.
> (see Kent Beck's book on this issue).
> You can always bring them in again later....
> Having too many unused things costs in the sense of unneeded
> distraction and second guessing of the users.
> Hannes

More information about the Squeak-dev mailing list