"Carl Mäsak" wrote:
> > What is the point of marking things readonly if you can turn it off?
>
> There are many possible reasons, I think.
>
> * The code that declares the variable readonly might not be available
> to you (compiled to bytecode, fetched by RCP etc),
> * or it might be available but used by other clients which expect the
> variable to be read-only.
> * You might be writing a one-time hack, which can be done the easy way
> by turning off read-only checking.
> * You might be writing test code, which is greatly simplified by your
> just reaching in an changing the damn thing.
>
> In short, I have no problem with _turning off_ read-only checking.
> That, I think, can be done on a suit-yourself basis.
>
> I'm arguing for having read-only checking at compile level (which
> everyone seemingly agrees on), and spec-requiring of a compiler to
> check this (and here opinions divide).
>
> // Carl
And that pretty much sums up about half of the traffic on this list.
Speculative considerations of theoretically possible scenarios without
any consideration of whether they would ever actually arise. Or be
useful if they did. The result is a spec so complex that there is
almost no chance of verification against it, even if enough people
understand the intersection between all the speculative what-ifs and
the few more concrete 'will's and 'must be's, to actually come close to
implementing it.
Perl made it's name by adopting the useful, pragmatic parts of other
languages, and leaving out all the abstract, purely theoretical and
only useful to one-legged, six-fingered theologians on wet Wednesdays
in October.
Sometimes it's a good idea to return to the beginning and ask yourself
why do we want this feature in the first place.
What does adding the ability to mark variables or parameters RO by the
programmer using the language?
In Perl 5, people are beginning to jump through hoops in order to
achieve encapsulation that cannot be subverted. Giving
module/subroutine users the ability to ignore the authors mutability
annotations makes them worthless.
What does adding the default assumption that subroutine or method
parameters are RO buy the language implementor?
This provision could be used my the language implementor to achieve
some extra level of efficiency by allowing them to hoist RO values into
registers; avoid locking of RO values in threaded environments; perform
compile-time constant folding and expression substitutions
(term-rewriting); and similar. The moment you allow the RO annotations
to be overridden at either compile-time or runtime, those optimisations
go out the window.
In other words, if you allow RO annotations to be overridden, all the
benefits that could accrue from having them go out the window, so you
might as well simplify everyones life and discard them all together.
Now maybe that's the way to go. Historically, the few places where the
readonly attribute is applied in Perl 5 it tends to create anomalies
and rarely improves performance. But if you are serious about providing
the facility, don't go screwing it up for the benefit of the six guys
in the world that could count their number on one hand, on one of four
days a year when the sun might shine anyway.
b.
--
