At 05:23 PM 8/28/2001 -0700, David Whipp wrote:
> > They list two reasons to make your class final. One is security
> > (which might actually be valid, but I doubt it will hold up to
> > determined attack), the other though...
> >
> > You may also wish to declare a class as final for object-oriented
> > design reasons. You may think that your class is
> > "perfect" or that,
> > conceptually, your class should have no subclasses.
> >
> > The idea that a class is either 'perfect' or 'complete' has to be the
> > silliest, most arrogant thing I've ever heard!
>
>The only good justification I've heard for "final" is as a directive
>for optimization. If you declare a variable to be of a final type, then
>the compiler (JIT, or whatever) can resolve method dispatch at
>compile-time. If it is not final, then the compiler can make no such
>assumption because java code can load in extra classes later.
This is the only real reason I've seen to allow final. (And it's not a bad
reason, honestly, though not necessarily one appropriate in all cases) It
does allow a fair amount of optimization to be done, which can be
especially important when you can't see all the source. (Pretty much the
case in all languages that compile down to object modules you link together
later)
You can, with sufficiently aggressive analysis, determine whether a class
is subclassed if you have a language that doesn't allow you to change the
rules at runtime, if all the source is available. Perl, alas, doesn't fall
into this class of languages, so we're going to have to do something
clever. (Probably some form of conditional branch--"Branch if not changed
since time X"--that checks to see if the inlined version's safe to use)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
