in reply to Modification of a read-only value attempted

I've never taken this approach when making a read-only variable (opting for using constant/Readonly, instead).

Question for other monks: How common/acceptable is an approach like OP's $c=\99;? Although concise, it is less readable (and probably easy to not notice). Thanks.

Replies are listed 'Best First'.
Re^2: Modification of a read-only value attempted
by choroba (Cardinal) on Nov 27, 2012 at 16:59 UTC
    This does not create a read-only variable, but a read-only value.
    لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ
      Oh, because you can actually assign something else to $c. Of course! Thanks
Re^2: Modification of a read-only value attempted
by mbethke (Hermit) on Nov 27, 2012 at 17:03 UTC

    You will notice when you try to write to the constant, which I suppose is the point of it :) That said, I do prefer Readonly as well because it allows for completely normal-looking "non-variables". Having to remember to dereference anything that's supposed to be a constant doesn't make sense except as an idiosyncrasy of the language. What's more, Readonly also lets you write-protect hashes and arrays although at a performance cost.

      This discussion reminds me of a related question. When a Readonly hash or array contains references, are the targets of those references protected? As a common example, are the elements of Readonly matrix protected?

      Bill

        Easy to test:

        >perl -wMstrict -MData::Dump -le "use Readonly; ;; Readonly my %h => (a => {b => {c => {d => 1}}}); dd \%h; ;; $h{a}{b}{d} = 2; " { # tied Readonly::Hash a => { # tied Readonly::Hash b => { # tied Readonly::Hash c => { # tied Readonly::Hash d => 1, }, }, }, } Modification of a read-only value attempted at -e line 1

        See also DESCRIPTION section of Readonly.