This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Smalltalk is not object-oriented enough!
Feed Title: Richard Demers Blog
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rademers-rss.xml
Feed Description: Richard Demers on Smalltalk
Of course, Smalltalk is light-years ahead of any other programming language (or development environment) in this regards. The typical Smalltalk brag is that it is "objects all the way down" -- no primitive types, full reflection, a comprehensive OO tool set, etc. Only, there are places where object-orientation and reflection seem to have been forgotten (at least in VisualWorks).
What is a "bundle" or a "package"? They are named entities, but how does one get program access to one, or to its properties? What "public" methods can be used to work with them? And why aren't their names contained within a namespace?
Instead, they seem to be just repository constructs that were added after-the-fact without being integrated into the Smalltalk domain model. Yes, there are undocumented Store methods for finding and working with them, but that isn't the same thing is it?
And then, there are class "categories" - hopefully to soon be a thing of the past - so we won't worry about them.
But what about "protocols"? These are just symbols hung off of each method to bring a semblance of order to otherwise unrelated groups of methods. Anyone can use any symbol as the protocol of any method. On the one hand, this gives programmers (at least those considerate of the readers of their code) a powerful "literate programming" technique for organizing and documenting code. But try to rename a protocol that spans multiple classes or packages, or try to keep protocol names consistent across a complex system; not easy things to do. And shouldn't protocols also be contained within namespaces?
These are symptoms of an underlying problem. The fundamental Smalltalk domain model needs work. Over time, it has been hacked to meet the needs of various tools, like Store, the Refactoring Browser, and the debugger. It should be made to accurately reflect the view of Smalltalk that is presented by the tools, the tools should be made to accurately and completely reflect the Smalltalk domain model, and the public methods of all Smalltalk domain objects should be clearly identified and documented.
VisualWorks Smalltalk is a joy to work with, but it could be even better -- by the simple expedient of being made more completely Object-Oriented.
Previous Topic
