ptalk > My Back Pages

My Back Pages

Stumbling around in the blogosphere I came across an article about Dylan, the programming language. Brought back fond memories. I still think it’s the coolest O-O language, but I have to program in the language that will pay the bills…

I have one quibble with the author: Dylan did not invent multi-methods. They have been around since Flavors and LOOPS.

My personal favorite feature that Dylan did invent is sealing, or perhaps more appropriately, opening. Dylan’s sealed and open declarations are the key to its balance of flexibility and efficiency. They let the developer of a module declare which classes and methods are permitted to be extended. This declaration allows the compiler to generate much more efficient code for the case where extensibility is not allowed (outside the module), without burdening the programmer with an excess of type and visibility declarations.

Quoting from Dylan Programming:

A C++ compiler could optimize out the dispatching of a virtual function by analyzing the entire scope of the argument on which the virtual function dispatches, proving that argument’s exact class. Unfortunately, that scope is often the entire program, so this optimization often can be performed only by a linker. Even a linker cannot make this optimization when a library is compiled, because the classes of a library can be subclassed by a client. The complexity is compounded for dynamic-link libraries, where there may be multiple clients at once. As a result, this optimization is rarely achieved in C++.

In Dylan, sealed classes, sealed generic functions, and sealed domains explicitly state which generic functions and classes may be extended, and more important, which cannot. The library designer plans in advance exactly what extensibility the library will have. The Dylan compiler can then optimize dispatching on sealed generic functions and classes and within sealed domains with the assurance that no client will violate the assumptions of the optimization. The sealing restrictions against subclassing or changing method applicability are automatically enforced on each client of a Dylan library.