Sealing and Implementation Inheritance


Ted Neward has some interesting stuff to say about “sealing” (really, Java‘s “final” and C++’s “protected”), but he fails to mention efficiency concerns.

In Ted Neward’s blog he has some interesting stuff to say about “sealing” (really, about Java‘s “final” and C++’s “protected”), though he only talks about design and fails to mention efficiency at all. The design issues surrounding implementation inheritance are important to consider, but Dylan sealing is also about—perhaps primarily about—efficiency, not inheritance design.

Allowing subclassing at runtime or outside a compiled library imposes a runtime cost. Libraries that use sealing can be compiled more efficiently, because they can take advantage of the boundaries imposed by sealing to allow elimination of runtime dispatching (and subsequently, inlining). That explains why “sealed” is the default in Dylan.

Of course, library designers need to consider making some things open for extension by other, separately compiled libraries. From a design perspective that probably means exporting open abstract classes and only providing methods for reasonable default behaviors—ie., minimizing the use of implementation inheritance and instead focussing on interface inheritance, as Neward suggests.

Posted: Mon - April 19, 2004 at 04:30 PM          

©