On Mon, 2002-05-20 at 00:27, Larry Wall wrote:
> Aaron Sherman writes:
> : > Alternately, I think we should be able to mark subs as 'final' or 'inline'
> : > to indicate our guarantee that they won't be modified. Of course, it'll
> : > conflict with auto memoizing or auto currying modules that'd want to
> : > override it, but that's their fault. :)
> :
> : Yes, I suggested "inline" or "const".... I can't imagine that we would
> : want to do without this, regardless of what we call it. Otherwise,
> : auto-accessors will always be slower than using the variable. Would
> : everyone agree that this property should default to being set for
> : auto-accessors?
>
> No, that would undo the whole point of making them accessors in the
> first place.
Think of this like a constant variable. In Perl5, we can do:
use constant foo=>1;
use constant foo=>2;
and foo will have the value 2, but you cannot change the value of foo
during run-time. That's all I'm saying for accessors. This way, when I
define
class argh {
my $.foo;
}
I get
method foo() is rw($newfoo) is inline { ... }
but, in another module, there's nothing to stop you from:
method argh::foo() { die "No, you don't!" }
because all that matters is that AFTER perl sees you call C<$obj.foo>,
it never changes.
Of course, this all goes out the window if inlining happens at
compile-time, since libraries will no longer be able to override
auto-accessors later on.
> : In this model, you only ever inline at load time ***OR*** when the
> : compiler is attempting to produce a self-contained byte-code executable
> : (e.g. one which has all of the modules in it), in which case it executes
> : that part of the load time process early. If you like, call this a
> : sub-stage of load time, which I shall dub "link time". Link time can
> : only happen once per program, so it must happen when we actually know
> : what all of the program components are.
>
> It seems like an assumption that link time can only happen once. An
> incremental linker might feel like it can relink any time it feels like
> it. Some very useful programs never completely know what their
> components are.
Agreed, and I would be remiss if I didn't mention that all good
intentions go out the window the moment someone does:
sub mumble() is inline { ... }
eval 'use stuff;mumble()';
Now, we could have the case where mumble has been redefined, or the case
where mumble is still the old inlinable thing, but inlineables that it
calls have been redefined.
Ick, *shudder*.
I guess the run-time checks will be required, and inlining of small
chunks of code will never really be all that useful (as you cannot rip
open that scope and optimize the whole context).
