Re: Sealing and direct-instance declarations

[john@linus.mitre.org]

Jonathan Bachrach (Jonathan.Bachrach@ircam.fr) feels that the current
class sealing mechanism is too limiting.

Mark Nahabedian (naha@RIVERSIDE.SCRC.Symbolics.COM) replies:

  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.

But you may want to ship not an application, but a library module
for others to use.  If you seal too much, the library may not be
extensible by another user, who will most likely wish to specialize
the leaves of your class hierarchy.  Conversely, you may not want the
user to know about the upper reaches of your class hierarchy, and so
the user does not know what classes to seal when HE is ready to ship
his application.

Now, he could just seal the "exported" leaves of your library module,
as those are the only classes his code references, but YOUR libarary
code probably references non-exported classes, and thus cannot be
optimized.  I think this is a real problem with the current sealing
approach, as I understand it.  I have to think about it some more, but
I think the "direct instance" declaration described by Bachrach would
not suffer from the same problems.

John Burger
john@mitre.org