[Prev][Next][Index][Thread]
Sealed as Source Annotation
-
To: info-dylan@ai.mit.edu
-
Subject: Sealed as Source Annotation
-
From: mkg@lanl.gov (Mark K. Gardner)
-
Date: Thu, 13 Jul 2000 15:30:02 -0400 (EDT)
-
Organization: Los Alamos National Laboratory
-
Reply-To: mkgardne@cs.uiuc.edu
-
User-Agent: slrn/0.9.6.2 (Linux)
-
Xref: traf.lcs.mit.edu comp.lang.dylan:12455
I would like to start a philosophical discussion of the merits /
demerits of directly annotating the source code to seal classes (or
make them final) versus having the annotations be external to the
source. I am cross-posting to Dylan and Java newsgroups as those two
languages are the only ones that I am aware of that allow annotations
which declare that a class will not be extended.
As background, I am a long time lurker to Dylan (having obtained
Apple's printed DRM within a short time after announcement). I have
played with Thomas and Mindy and have built d2c but have not
programmed anything useful. Indeed I have done almost no programming
in Dylan at all. I have programmed in Java extensively and thus my
experience has been exclusively with Java's final class annotation.
Question: Why are internal (i.e., direct source) annotations better
than external annotations?
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.)
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. Finally, the need for annotations should
decrease as compilers become better at determining for themselves what
should be sealed and what should not. From my perspective, external
annotations appear to complement smart compilers better than do
internal annotations. (By way of analogy, most modern C compilers
ignore the "register" keyword and determine for themselves which
variables should be kept in registers unless a compilation flag is
set.)
On the other hand, external annotations increase the complexity of the
build process by virtue of the fact that some of the information
necessary to determine the semantics of the source is not contained
within the source. In spite of this, I am leaning toward external
annotations over internal ones.
What are the counter arguments in favor of internal annotations?
Mark
--
Mark K. Gardner
RADIANT Team
Network Engineering, CIC-5
Los Alamos National Laboratory
P.O. Box 1663, M.S. D451
Los Alamos, NM 87545
Email: mkg@lanl.gov
Phone: 1-505-665-4953
--
Follow-Ups: