On Tue, Sep 04, 2001 at 09:30:19AM -0700, Hong Zhang wrote:
> > 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)
>
> If our intention is only for optimization, I prefer to use word "inline"
> instead of "final". The word "final" already has been abused. It is very
> awkward to use it for this purpose.
Ummm... there should be no *language* reason why we can't override
inline methods. It's purely an internal distinction.
The unfortunate problem with saying "inline methods cannot be
overriden" is people are not going to realize this, slap 'inline' on
their methods (cuz it's faster, you see) and screw their subclassers.
Or they will realize it and slap it on anyway, either because they
think the speed is more important than subclassing, or because they
really want 'final'.
Trying to optimize methods so they are "inline" in a dynamic language
like perl is going to have all sorts of weird side-effects. Object
method calls are currently only about 15% slower than function calls.
I expect that gap to close in Perl 6 just with the introduction of
proper vtables.
Preventing subclassing is not worth 10%.
--
Michael G. Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
This is my sig file. Is it not nify? Worship the sig file.
http://www.sluggy.com
