On Sun, 14 Sep 2003, Gordon Henriksen wrote:
> On Saturday, September 13, 2003, at 11:33 , [EMAIL PROTECTED]
> wrote:
>
> > On Sat, 13 Sep 2003, Luke Palmer wrote:
> >
> > Of course having a "no subclasses" tag means the compiler can change a
> > method call into a direct subroutine call, but I would hope that method
> > calling will be fast enough that it won't need to.
>
> A strategy to actually keep that optimization, and apply it to much more
> code, would be that the JIT compiler could optimize for the case that
> there are no known subclasses, and pessimize that only if a subclass
> were later loaded.
>
> I think this is one of the features Leo's been on about with respect to
> notifications.
That's one of the reasons notifications were designed in, yes. There's a
growing body of interesting work on what's essentially disposable
or partially-useful optimizations. Given the dynamic nature of most of the
languages we care about for parrot, throwaway optimizations make a lot of
sense--we can build optimized versions of functions for the current
structure, and redo them if the structure changes.
This isn't entirely an easy task, however, since you can't throw away or
redo a function/method/sub/whatever that you're already in somewhere in
the call-chain, which means any optimizations will have to be either
checked at runtime or undoable when code is in the middle of them. (Which
is a decidedly non-trivial thing, and impossible in general, though
possibly not in specific cases)
I don't see any reason to not allow marking a class as final (though
that's not hugely useful), closed (which is far more useful), or declared
objects as exact types rather than subtypable. (Which is, in conjunction
with closing a class, hugely useful)
Which is to say that marking a class as unenhanceable and Foo variables as
holding *only* objects of type Foo and not child classes, gets us a lot
more than marking a class as final. (Which does the same thing, but
globally, and not necessarily usefully)
Dan
