direct-instance declarations

[patl@goldfish.mitron.tek.com (Patrick Logan)]

   From: Mark Nahabedian <naha@RIVERSIDE.SCRC.Symbolics.COM>
       From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>

       Sealed-classes provide a mechanism for reducing dispatching, but
       unfortunately the current mechanism is limited in annoying ways.
       First, dispatching is performed at compile-time for only
       sealed-classes at the leaves of the class heterarchy.  This prevents
       creating efficient instantiable classes with subclasses.  Secondly,
       after sealing a class it is forbidden to create a new subclass for
       that class.  

   I don't see this as a significant restriction.  I would see myself not
   sealing a class untill I was ready to build a "shipable" executable of
   my application.  At that point there is no longer a development
   environment and there is no possibility of adding subclasses anyway.  I
   don't think it's a big disadvantage to not seal a class until the
   development cycle is over.

		    This means, for example, that none of the code for the
       classes in the sealed collection classes can be leverage -- for
       example it is impossible to create a new <table> subclass with a
       slight variation.


What about a scenario like the following: a class is given one
subclass that adds no new functionality but is sealed. Other
subclasses can be made that add functionality, but instances can be
made of the sealed class for the benefits that sealing provide.

			    Super Classes
                              \  |  /
			       \ | /
				\|/
		     Class-that-can-be-subclassed
                             /           \
			    /             \
			   /               \
Sealed-subclass-with-no-new-functionality   \			     
				            Other subclasses

--
Patrick Logan         patl@goldfish.mitron.tek.com
Mitron Corporation    (503) 690-8350    FAX: (503) 690-9292
15256 NW Greenbrier Pkwy, Beaverton, OR 97006