[Prev][Next][Index][Thread]
Re: Sealed as Source Annotation
Bruce Hoult bruce@hoult.org on 2000-07-13 20:45 wrote:
[...]
>> My experience with Java has indicated that internal annotations are a
>> problem. By declaring a class final so that it cannot be modified, we
>> are presupposing that the class is complete and needs no modification
>> or extension. Invariably, however, the class is not complete for all
>> uses and yet it cannot extended because it is final. The programmer's
>> only recourse is to duplicate the functionality of the finalized class
>> and then to extend it. This is clearly wasteful of the programmer's
>> time, as well as system resources. (As an example, there have been
>> discussions concerning the need to declaring Java's String class final
>> for efficiency reasons and the attendent limit on extensibility.)
>
> Dylan avoids this problem to a large extent by allowing subclasses to be
> declared in the same compile unit with the sealed class. So it is not
> that the class has *no* subclasses, but that the list of possible
> subclasses is fixed and known to the compiler (and in many cases is
> empty).
Also, Dylan permits open subclasses of sealed classes. This is a variation
on having a sealed subclass with an open base class. In either case, a
sophisticated compiler could use "copy down" to create both efficient
methods for the sealed domain and flexible methods for the open domain of
the class.
[...]
>> It appears to me that declaring the class to be sealed outside the
>> source would allow extension where appropriate without "code reuse by
>> copying". Additionally, having the annotations external to the source
>> naturally leads to allowing specific instances to be sealed while
>> leaving others unsealed.
>
> I'm sorry. I don't understand your intent. Do you propose that
> particular *instances* of some class might be sealed/final, but that
> other objects of that class will not be? How would that work? What
> would it mean? As I understand it, sealed/final is an attribute of a
> class, not of an object. [bindings can also be final (called "constant"
> in Dylan), but that's an entirely different thing]
It sounds like he might be asking that there be a link-time optimization
that could seal the class when I don't need to extend it, but otherwise
leave the class open?
I think I disagree with this idea, because I think part of the design (and
contract) of a class is whether you expect it to be extended or not. A
class that you design to be open requires much more engineering than a
sealed one.
Follow-Ups:
References: