Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation

grab bag of user questions

by ysth (Canon)
on Nov 04, 2003 at 14:52 UTC ( #304431=monkdiscuss: print w/replies, xml ) Need Help??

(updated with some paraphrased answers, apologies for any misattributions)

Is there a way to preview an update?

Answer: editors can preview their updates, so perhaps someday but don't hold your breath (tye)

How should a wrong (or only 25% right) answer in Q&A be responded to? I see this done two ways: via reply and via a separate answer. The reply doesn't show up in the list of answers, so seems kind of pointless unless someone goes and edits the answer, and a separate answer doesn't visually tie to the error its correcting. If the error is repeated in more than one answer, it feels as if the correction is being out-voted.

Answer: two monks, three opinions

How can I see what writeups of mine have recent replies?

Answer:set user settings to notify your message inbox when a node you wrote gets a reply (davido)

I see "Perl documentation on this site is out dated". Is there any interest in updating it? Or is it a deprecated source of perl doc?

Answer: too much effort, link offsite (davido), teach them to use local docs for their particular perl version (tilly)

Replies are listed 'Best First'.
Re: grab bag of user questions
by davido (Archbishop) on Nov 04, 2003 at 16:34 UTC
    First question... The Q&A section isn't really a discussion section. However, on occasion, wrong answers get posted. If you spot a wrong answer you can post a followup to that answer. But as you've mentioned, from the Q/A page, you don't see the followups. My suggestion is, once you've posted your followup, send a /msg to QandAEditors alerting them to the issue, and to your followup. The QandAEditors can rework the errant "answer", incorporating your correction, or remove the wrong answer altogether.

    If you don't feel like posting a followup with a correction, you can still alert the QandAEditors via /msg. They'll take care of fixing or removing it.

    And definately use your own judgement. If your response is actually "Another way to do it", that might be a "better way", it's possibly not so much a correction as simply another good answer. If that's the case, post it as an answer, not as a followup.

    2nd question: You can turn on a setting in your user settings that will cause your inbox to be notified if someone replies to a node you wrote.

    3rd question: I can't really comment on why the documentation is outdated (other than the fact that it's probably pretty labor intensive updating it every time a new release comes out). But for those times when you want to link to the POD, and the on-site version is substantially or significantly outdated, you can link to the POD at


    "If I had my life to live over again, I'd be a plumber." -- Albert Einstein

      No, there is no preview for updates, but you already knew that. We have preview when editors make updates, so such a feature is feasible. I don't expect schedules from volunteers so I won't say anything more about when such might become available. Certainly don't hold your breathe. (:

      I think a scheme that might scale better would be to post an improved answer and let Q+A Editors remove duplicates (and do other clean-up if needed).

      1. This allows all to notice the improved answer immediately (even if it takes 2 weeks for a Q+A Editor to do something about it)
      2. This means all can help with improving the content instead of forcing only Q+A Editors to write improved "copy"
      3. This likely reduces the amount of admin work required by editors (Q+A Editors can't delete replies to answers so they'd have to get 3 editors to help them, while they can, acting alone, delete a duplicate answer)

      For trivial updates, a /msg to Q+A Editors is probably preferred.

                      - tye
      Thanks. (You actually answered questions 2 through 4, not 1 through 3.)

      BTW, seems to be out of date also. is updated 6 times a day, though (see cpan: module and perldoc: links)

      (Update: To clarify my point, I am not advocating online docs instead of local use of perldoc. I'm responding to

      for those times when you want to link to the POD, and the on-site version is substantially or significantly outdated, you can link to the POD at
      by mentioning that is itself out of date, and there is another resource that is updated to 5.8.1 and will automatically be updated to 5.8.2 as soon as it is released.)
Re: grab bag of user questions
by tilly (Archbishop) on Nov 04, 2003 at 19:35 UTC
    My answer to the last question. I think that people should be encouraged subtly and unsubtly to rely their local documentation (accessible through perldoc). That is the only way to get documentation with any guarantee that its advice should match the version of Perl that you are using. Any version of Perl that they choose to document here will be wrong for a large fraction of users who might try to use it.
      I have the feeling that perl documentation is more often updated to correct errors or clarify things than to match new functionality. It follows that newer doc will sometimes be a better choice even when using an older perl.

      But I think we would both agree that that pales next to the importance of training users to independently consult their documentation.

        If you believed the next version's documentation, here are errors that you would have had from various versions of Perl:
        1. In 5.003 you would have been left thinking that foreach my $var (@list) {...} should work, and would have wondered why it did not.
        2. In 5.004 you would have thought that you could use substr to replace text, not just extract it.
        3. In 5.005 you would have thought that our was a usable keyword and warnings was a usable module.
        4. In 5.6 you would think that you could have the new (and far more stable) threads implementation available.
        I have either had or seen people who had questions about every one of these. For instance take a look at RE (3): Should I use $ and $# ? which is from a thread here caused because someone who bought the third edition of the Camel tried to use our in Perl 5.005_03 and then got confused. See RE: Perldoc's vrs. Books, and RTFM's from around the same time period. Since then my opinion about the importance of local documentation has not changed, although I have a better understanding of why people have trouble understanding things sometimes.

        Now I haven't done any kind of survey to find out what kind of documentation patch is most prevalent. However my gut tells me that documentation far more often gets added than significantly rewritten. And added documentation is very often documentation added to describe new features which won't be there in old versions.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: monkdiscuss [id://304431]
Approved by Corion
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (8)
As of 2018-06-22 22:00 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (124 votes). Check out past polls.