[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Sealing and direct-instance declarations
- To: email@example.com
- Subject: Re: Sealing and direct-instance declarations
- From: firstname.lastname@example.org
- Date: Fri, 06 Nov 92 10:53:00 EST
- Posted-date: Fri, 06 Nov 92 10:53:00 EST
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
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.