This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: More thoughts on sealed/final
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
There's been a lot of talk about sealed/final since I posted here. In various posts (like this one from Ted Neward, the assertion is made that languages like Java and C# (any CLR based language, actually) need this capability, while Smalltalk doesn't. That sounded wrong to me, but I'll get to it. The other argument came across in a brief conversation I had with Joshua Bloch after this talk at ot2004. The argument goes like this: There's a pyramid of developers, with elite developers at the top (in small numbers) - with most living at the bottom two rows of the pyramid. making classes "final" protects this class of developer from themselves. I've pondered these two arguments, and had a few conversations about them on the Smalltalk IRC channel, with people who have experience with Smalltalk, Java, and C#. Here's what we came up with:
In Java, interface inheritance is the way to do things. A change in the API or semantics of the interface will ripple through all users - even though they aren't inheriting from the base class. So exactly what have you saved people from? Nothing except the option to inherit from a class if they wanted to take on that responsibility. So posit a class SecurityChecker and a method checkPassword(). That method should only take an instance of String, not some subclass or compatible class. That kind of security is arguably ok - but making it impossible to subclass String for any reason, ever - is overkill. The controls belong at a finer grain. What "final" ends up doing is cutting off your nose to spite your face. Here's a question: who's in a better position to know whether subclassing is appropriate:
The library developer who has never seen the end developer's code
The end developer who has seen both the framework and the end developer code?
Ted and Joshua Bloch say the library designers are in the better position. I say that's just silly - it really is akin to deciding that you are going to protect your children from all possible harm that could come to them by standing next to them 24x7. Sure, they'll be better protected. They'll also grow up as less than adults. This kind of protection means that developers have lots of (potentially better) options closed off to them, and they'll create crufty code. Worse, they'll start thinking that it's a good idea. The protection extended to them has ended up crippling them.
So now we come to arguments that Whidbey (the next gen of VisualStudio) should declare classes final by default, forcing developers to open them if they so choose. For the reasons given above, I think this is an awful idea. It will end up creating inflexible code - and since api changes ripple through a declared interface anyway, it offers few of the supposed benefits. I really have no idea why anyone thinks this is a good idea...
Previous Topic
