http://qs1969.pair.com?node_id=947042


in reply to Re^18: ref to read-only alias ... why? (notabug)
in thread ref to read-only alias ... why?

If it were true, why then threaded and non-threaded perl give different results in \ $_[0] ?

I don't know why that code isn't reached for non-threaded Perls.

Even if it was, that's bad intention to me, and bad design. A bug, basically.

You're wrong to simply declare that it's a design flaw.

Three people in this thread and many of the core Perl5 developers (if not all) know that it's not self-evident that literals should create non-modifiable values.

You're wrong to simply declare that it's a bug.

It's only a bug if it doesn't behave as intended, and some of the core Perl5 developers have explicitly stated they believe literals should return modifiable values.

I was hoping you'd come around to expressing an opinion or making an argument, but all we got were empty declarations.

Replies are listed 'Best First'.
Re^20: ref to read-only alias ... why? (notabug)
by dk (Chaplain) on Jan 10, 2012 at 18:33 UTC
    ...many of the core Perl5 developers (if not all) know that it's not self-evident that literals should create non-modifiable values. You're wrong to simply declare that it's a bug.

    I'd like a proof to that statement. My arguments, on the contrary are quite simple: the behavior is not documented, the behavior is inconsistent. If that doesn't qualify for a bug, then I don't know what does. If you can prove that the behavior is documented, and that it is consistent, please do.

    some of the core Perl5 developers have explicitly stated they believe literals should return modifiable values.

    Proof please. Again, my proof is that Arthur Bergman, the person who answered to the bug some 8 years ago, said it's a bug. https://rt.perl.org/rt3/Ticket/Attachment/55414/41707/

    I was hoping you'd come around to expressing an opinion or making an argument, but all we got were empty declarations.

    I'm sorry, but empty declarations are on your side :) You didn't provide neither proof in docs/code, nor references in support to the claims that many (how many "many" btw? "many" as in "one-two-many"?) devs support your claims. Please, either show hard facts or admit that you have none.

    I'm ready to accept your point of view, but you need to corroborate it.

[reply]

      I'd like a proof to that statement.

      There are comments on RT#3105 that were posted on p5p (but off-ticket) about this. Also, COW came up again recently on p5p. It's a publicly readable and searchable mailing list. I don't have time to search right now (Took me a couple days just to get around to writing this!) I'll try when I can.

      my proof is that Arthur Bergman, the person who answered to the bug some 8 years ago, said it's a bug.

      Just like him, I agree the inconsistency is a bug. I only have a problem with your fix. I have already explained how I think your fix only affects the case that is working correctly.

      how many "many" btw? "many" as in "one-two-many"?

      Considering there's only a couple of handful of them in total, and how few speak on topics they aren't working on...

      You didn't provide neither proof in docs/code,

      To my knowledge, the docs are silent on whether literals should return read-only values or modifiable values. Which is why I provided code (contrary to what you said).

[reply]
        Just like him, I agree the inconsistency is a bug.

        Gaaah! Why didn't you say that earlier? I was sure you meant that it's not a bug. Good we're coherent at last.

        I only have a problem with your fix.

        Well I wouldn't insist on it; I posted it because I thought it's better than nothing, than a bug that slept for 8 years. I don't have the competence though to make a more proper patch, but I do hope that at least my incomplete patch stirs attention and something will be made on the issue.

[reply]
Re^20: ref to read-only alias ... why? (notabug)
by LanX (Saint) on Jan 11, 2012 at 02:10 UTC
    Well you already agreed that it is inconsistent.

    And for some people - including me - inconsistencies are a special quality of bugs. (maybe the worst)

    OTOH I'm well aware that it's not possible to simply redesign implementations w/o breaking other code depending on old behavior.

    So it's a matter of best compromise - like emitting warnings.

    Cheers Rolf

[reply]

In Section Seekers of Perl Wisdom