This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: More on 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. Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Cincom Smalltalk Blog - Smalltalk with Rants

Gary Short links to Eric Gunnerson discussing the whole idea of sealing classes. The long and short of it - Eric thinks that library designers know everything and that one of the primary jobs is to protect . There's just no telling what they might do if we let them.

My reasons have everything to do with predictability and robustness. If you can't conceive of a user extending your class in a specific way but still choose to provide such extensibility, then it's pretty clear that you don't have an extension scenario in mind, which means that neither your code nor your tests are likely to ensure that it does work - especially across versions. Sure, it's possible that it may work in the current version, and may even continue to work in future versions, but I wouldn't call it a supported scenario. I'd prefer to use classes where I know what I'm doing is supported.

The second issue is around understandability. If I walk up to a class (in the metaphorical sense, of course, you can't really 1Cwalk up 1D to a class) and it has 29 virtual methods, it's hard for me to tell whether the author *intended* me to extend the class through a certain method or set of methods, or whether they just left them virtual 1Cjust in case 1D. Where if a class only has one (or a small number) of virtual methods, that's a good indication that the designer wants me to use them (ie they're part of a supported scenario).

So, if I (as the application developer) can't see the author's intent, I shouldn't be allowed to subclass? I'm sorry, but that's just stupid. Yeah, that's the word I want. Who's in the better position to determine what needs to be done on a project - the application developer (who's actually there and sees the problem first hand), or the library designer, who likely built the set of classes in question in isolation? According to Gunnerson, the library designer has a better viewpoint on this - and gosh forbid I put the code to any use but the one that the original designer intended. Better to build a brand new set of classes than question the original design. This kind of thinking makes me wonder.... a lot.