chromatic wrote:
> The point is not for module authors to say "no one can ever extend or
> modify this class". It's for module users to say "I'm not
> extending or modifying this class".
Ah, shouldn't optimization be automatic? Much preferrable to provide
opt-out optimizations instead of opt-in optimizations. C++ const
qualifiers, anybody? final in Java? Compressable line noise in most
programs, those.... Even--especially--programmers who are writing code
in main:: can be naïve of the code they call; they're no more
trustworthy than the module author. It's the local user of a class which
knows what's going on, and not even then in the case of polymorphic
classes. The optimizations enabled by final/sealed are very broadly
applicable to most code; would be good to turn them on by default and
automatically turn them off when they become inapplicable. DWIM +
performance + flexibility. Thus the notifications discussion.
If method call->function call optimization were dicking with a routine
and making it misbehave (e.g., forcing excessive recompilation), though,
I would want to see a plain old pragma to broadly turn off the
optimization. Just:
no optimized <method_calls>;
That way, I could move the pragma down as far as an unnamed block, if I
wanted to isolate its effects to one method call, or as far out as the
entire module if I was lazy and wanted to do that instead. But no
I-promise-not-to-override-methods-of-this-class-anywhere-in-the-entire-p
rogram pragma for me, thanks. Way too much action at a distance.
Potentially disruptive optimizations, off by default, could be
intuitively enabled by the same pragma, too:
# Try hard to vectorize hyper arithmetic for SSE and AltiVec.
use optimized <vector_hyper_ops>;
And it sets up a namespace for optimizations, which might help make
optimizations extensible, transparent, or even pluggable.
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
