Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things

Re^6: Shouldn't references be readonly? (updated)

by ikegami (Patriarch)
on Aug 07, 2020 at 19:54 UTC ( #11120476=note: print w/replies, xml ) Need Help??

in reply to Re^5: Shouldn't references be readonly? (updated)
in thread Shouldn't LITERAL references be readonly? (updated)

@a = map { $_ = 3; } [];

is no more or less junk than

@a = map { $_ = 3; } $x.$y;

Are you therefore talking about [] + 1? Making the reference read-only is not going to catch that.

Replies are listed 'Best First'.
Re^7: Shouldn't references be readonly? (updated)
by LanX (Sage) on Aug 08, 2020 at 01:17 UTC
    There are far more situations where it might make sense to append or add something to a simple type.

    Not so with refs, no way a .= or a += will lead to anything meaningful.

    Well except when blessed and overloaded. But that's far fetched.

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery

      Making the var read-only won't prevent concatenation or addition, so it doesn't matter that $x . [] or $x + [] doesn't make sense.[1]. This isn't relevant to the topic at hand.

      The only thing making it read-only will do is prevent assignment, and map { $_ = 3 } $x.$y makes no more sense than map { $_ = 3 } [].

      Either prevent both of them, or prevent neither of them. No need for baseless inconsistencies.

      1. That said, $ref+0 makes some sense for refs to things other than objects with overloads, and both concatenation and addition make sense for refs to objects with overloads (which aren't farfetched at all!)

        Note that assigning to certain "unassigned scalars" is legitimate, such as the one returned by substr. Unassigned scalars with set magic simply wouldn't be made read-only, of course.

        But you know what else wouldn't be made read-only? "Unassigned scalars" from XS code. Making unassigned scalar *created by Perl* read-only would create inconsistencies with those created by XS code. This reduces the benefits of making any change.

        My point is about potential problems in backwards compatibility.

        A transformation of a string or a number into another string or number is common, BUT the transformation of refs is impossible.

        Hence it's far more likely that legacy code will break if something like $_++ became illegal for an aliased input like 3+4 .

        Same code for refs wouldn't make sense at all.

        I can't come up with more intuitive examples, but I'm sure those exist.

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11120476]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (2)
As of 2023-06-07 01:37 GMT
Find Nodes?
    Voting Booth?
    How often do you go to conferences?

    Results (29 votes). Check out past polls.