Re: Xerces and static mutability

[Joseph Kesselman]

>I'd be very interested in knowing in what situations you consider final
>not to be appropriate?

Random architectural blathering follows. It seems to halfway make sense to me, but half an hour from now I may conclude I was being a halfwit; caveat lector.


If it really is a value which is set once and never altered, and which no subclass will ever want to set to something different, final is the right thing. But excessive use of final does tend to hamstring attempts to subclass, including both experimental and production subclasses.

And there is a pervasive myth that final automatically means faster, which has often caused folks to use it even when subclassing _is_ a potential issue, which is a Really Bad Thing. I grumped at some developers rather loudly (and rudely, I admit) many moons ago when someone started slapping "final"s all over a DOM implementation in the hope that this might make it run faster, at a time when people were very definitely subclassing that DOM to experiment with things like signatures and SVG and so on.

Making the kidOK table final means that an extended DOM which wants to add a new node type can't simply override that table; they'd have to rewrite the code that consults it.. In fact, I do believe that most folks _shouldn't_ be adding new node types to the main DOM tree; the same effects can usually be achieved by using elements/attributes/PIs appropriately, so after consideration I think I'm willing to have that locked down for now. But note that this prevents someone from easily using subclassing to prototype an extention to the Document Type tree (eg to provide a more complete DTD model) if that extention involves adding children to the entity and attribute defintion nodes...

That can be worked around if access to the table is always through an accessor method, of course; just override the accessor to look elsewhere for its rules. But accessors impose some overhead, which is why

So, yes, final is helpful in detecting coding errors. But it also has costs, limiting what you can do without altering the class to rip that keyword out again. Consider whether future growth might make final a step in the wrong direction. Of course you can always change it back... the question is whether someone should _have_ to clone the package and change it back before deliberately altering it.

Sometimes final is the right answer. Sometimes it isn't so obvious. Sometimes the value should be final but the accessor shouldn't be. Sometimes both should be final but the object should be considered only one instantiation of a sufficiently complete abstract interface that, if you don't like the locked-in version, you at least have the option of reimplementing it from scratch and plugging the replacement into your system...

______________________________________
Joe Kesselman / IBM Research