Why being able to add methods is good
Charles Miller finds seven different StringUtil classes in his Java project - as opposed to the one String class in my Smalltalk project. Why? Because I can directly extend String. Here's the part I find interesting:
Today, I found myself wanting to do a pretty basic String operation that wasn't on the main class, so I sent IDEA ooff hunting and there were seven classes in my Classpath called either StringUtil or StringUtils, all of them from different projects.
So I wrote the method myself. Finding the one I should have been using amongst that lot was just too much effort :)
Just one more reason why there tends to be less duplication in Smalltalk; things go where they belong...
Comments
Re: Why being able to add methods is good
[Rich Demers] January 7, 2004 11:06:39.514
Comment on Why being able to add methods is good by Rich Demers
OK, so Smalltalk has one String class that can be easily extended by extending the String class in a different package, which I can then optionally share. A lot of different packages do have such extensions to String, with many of them having duplicated extensions. This leads me to wonder if there is really that much difference from the Java situation. If I don't know about an extension in someone else's package, or I can't be troubled to go search it out, then we're still rewriting methods -- and for the same reasons.
What's missing is a community mechanism for evolving both the Smalltalk language and its class libraries. What's needed is a way for programmers to propose changes, for others to try them, for people to (somehow) vote on changes, and for changes to be then included in the language.
Untitled
[lvovin] January 8, 2004 1:51:46.657
Selector namespaces is the answer - another dimension in organizing Smalltalk objects.