"Carl Mäsak" wrote:

> ] Oh, but it gets even better: it turns out they didn't really have to
> ] sneak in through native code anyway, at least as far as the JVM is
> ] concerned, since the JVM treats final variables as always writable
> to ] the class they're defined in! There's no special case for
> ] constructors: they're just always writable. The javac compiler, on
> ] the other hand, pretends that they're only assignable once, either
> in ] static init code for static finals or once per constructor for
> ] instance variables. It also will optimize access to finals, despite
> ] the fact that it's actually unsafe to do so.

I'm pleased to note that you made my point for me. 

Sure, you can sneak in under the covers of the JVM and compromise the
immutability of its final data. But you do have to sneak in. And when
you do, and things go belly up in interesting ways, or worse continue
to run but produce mysteriously wrong output, don't go running to blame
either the Java spec or the JVM. Their writers made their
optimisations, and the proofs of correctness of those optimisations,
and proof of correctness of the entire system, based upon the
specification of final. You hack it. Your problem.

But, if you add *is ro* to the P6 spec and then specify a way for users
to ignore or turn it off, and you render it entirely worthless. Indeed
it's worse than worthless because it is extra complication for no
benefit. If it doesn't allow the compiler writeres to make any extra
assumptions, it's just tying up space in symbol tables, consuming
cycles in the parser, and most damningly, mindspace in the spec and

If you add it to the spec. Mean it. If you don't mean it, don't add it. 

If you mean it, but it doesn't initially get implemented that's fine.
Someday it might and someday we might benefit from it.

Add it to the spec whilst offering a way to ignore it and you've wasted
everyones time.



Reply via email to