You made $c point to a constant: $c=\99;; hence when you try to modify that constant by indirecting through $c: $$c=1000;; Perl won't allow you to do so.

Nor should it.

Thanks for the Reply. Please clarify one more doubt. 1.) $c=99; Here $c is var which is holding 99 as value. We can change $c here ? 2.) $c=\99; Here also $c is reference which is pointing to 99. So why we can't change $c=1000? Thanks in advance

panku:

You can change $c=1000. What you can't do is change 99 to 1000. When you use $c=1000, it tells perl that $c is no longer pointing to a reference to the constant 99, but is now containing the value 1000. When you use $$c=1000, you're telling perl to change the thing $c points to to 1000. But $c points to the constant value 99. Perl is telling you that it refuses to break the time-space continuum by making 99 be 1000.

...roboticus

When your only tool is a hammer, all problems look like your thumb.

So why we can't change $c=1000?

As roboticus points out, you can make that change. That is, you can overwrite the value in $c -- currently the address of the constant 99 -- with any other value.

What you cannot do is overwrite the value held at the address held in $c, because it is a constant.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP Neil Armstrong

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.

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

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