Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Responsibilities of a module author

by xdg (Monsignor)
on Nov 23, 2005 at 17:41 UTC ( #511185=perlmeditation: print w/ replies, xml ) Need Help??

In Can I please have *simple* modules?, I was struck by this comment by Ovid:

Personally, I've sent plenty of bug reports to authors. Sometimes they fix them. Sometimes they ignore them. I've sent plenty of patches to authors. Sometimes they use them. Sometimes they ignore them. Sometimes I've just sent a damned tarball with everything working only to receive no response. In fact, there's one piece of software I use regularly which I've patched locally because I've been waiting over a year for the author to keep his promise to incorporate my patch (I'm not naming the code but I'm pretty annoyed by this).

I've run into this myself, and I know that at least one of the Phalanx projects has similar trouble -- when the author even explicitly agreed up front to have his module reviewed.

I suppose I shouldn't be surprised at this. One downside of using things that are "free as in beer" is that sometimes you get what you pay for, or rather, you don't get what you don't pay for -- and that means support and bug fixes.

An often heard refrain from module authors is "patches welcome". That's a good sentiment -- patches should be welcome -- but that answer doesn't substitute for taking responsibility to fix one's own bugs. The author may really mean "I don't have time to fix that right now, if you can fix it, I'll incorporate it" but without an explicit response that indicates the author intends to fix it "eventually" it sends the message that this is not a module the author cares about keeping up. This is particularly true when patches are submitted and then sit idle. That's fine -- it's free work after all -- but it matters to potential users who are concerned about whether they can depend something over the long term.

(Of course, the hassle of unravelling bug reports can be high and that create a barrier of inertia for fixing it, but that can be addressed in part by encouraging bug submitters to use test-driven bug reports, instead of brushing them off with "patches welcome".)

I think this is part of the reason why some Perl authors only want to rely upon the "core" modules -- there's a minimum committment from the Perl porters to maintain it. That got me thinking about what practices I'd like to see from module authors in general. Here's a beginning list.

Responsibilities of a module author:

  • before submitting a module to CPAN: don't release it to CPAN unless you're willing to commit to support, or at least explictly note your intended level of support (including 'none') in the module documentation

  • when a bug is reported, whether by email or on RT: always respond to the report if only to give an indicated priority and expected time to fix

  • (Addition) when a patch is offered: test the patch and either incorporate the patch or explictly reject it, all within a "reasonably" short period of time

  • if an author doesn't have the interest/bandwidth to maintain a module: offer co-maintenance to an interested party to take over or release an update to CPAN that note that module support is ending

Of course, a list of responsibilities may or may not be heeded. Several thoughts occured to me as ways to improve the feedback loop to encourage module maintance. As an old boss described to me, "some people are carrot people, some people are stick people, it's important to know which" -- so I started brainstorming ideas on both sides:

Ideas for improving the author feedback loop:

  • money talks -- if some functionality is critical, offer to pay the author a bug bounty to bump the priority over other things

  • name and shame -- several variations:

    • add negative reviews to cpanratings for modules where the author doesn't respond to bug reports in a reasonable time

    • add author reviews in addition to module reviews at cpanratings

  • name and fame -- create a new, annual community award (or awards) for "best maintenance" of an existing module and honor a half-dozen people a year or so for their efforts

  • count the tickets -- make more distribution statistics from rt readily available, such as number of bug reports outstanding; trend of bug reports opened/closed in last month, quarter, year, etc.; longest open bug report, etc.

What do you think of these ideas? What other suggestions do you have for module-author responsibilities and practices or for how to improve the feedback loop between bug reporters and module authors?

Updates:

  • Yes, this should have been about CPAN contributors, not "module authors". Pardon my narrow vocabulary.

  • Feedback has made me realize that my meditation drifted from the instigating idea about how module authors deal with patches. I've added a point above about that. I have no problem with module authors not fixing things -- as long as they communicate about it. To me, it should be common courtesy to at least reply to someone who reports a bug, and even more so if someone goes to the trouble to offer a patch. My suggestion around responsibilities also covered recognizing when it's time to turn over the reins to someone more interested in maintaining a module -- and maybe that was really the point I should have made about patches that just sit idle.

  • Struck the comment about "not uploading to CPAN" -- it seems to have sparked responses well out of proportion with what I'd intended. (I'm boggled that some people seem to think that guildlines like this could ever be "enforced", but I don't want to distract from the underlying message.) I left the point as explicitly noting the level of support, including 'none'.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Comment on Responsibilities of a module author
Re: Responsibilities of a module author
by BrowserUk (Pope) on Nov 23, 2005 at 18:11 UTC

    Take this with as big a handful of salt as you feel it deserves given my non-CPAN author status. It's just the thought that went through my mind.

    How about making it possible to move individual cpan modules into a "community branched state".

    That is, if say three or more users register themeselves as interest parties to a given module, and there is a high degree of consensus amongst those registered for the application of a patch that the author has either refused or failed to respond to, then the module gets forked on cpan into a community maintained subgroup, with a pointer from the author's version to the community maintained version.

    The registered interested parties take responsibility for approving and supplying patches.

    If the author of the package decides to merge the versions back together, the community maintained version gets expunged.

    If the author chooses to relinguish or co-own with one or more of the interested parties, then the author version gets expunged.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      With a meta-grain of salt, I'd have to say that I agree with BrowserUk's general idea of a standard, non-hostile, non-emotionally charged protocol for continuing the evolution of a CPAN module when its original author has expressedly or de facto suspended the support for it.

      I also agree with Perl Mouse when he says that "CPAN is just a repository. The great thing is that anyone can contribute any code to it.". Precisely, IMHO, it should be possible to contribute any code to solve any given problem, not just problems where no author before has planted its flag.

      In this sense, I feel that thought could be given to a natural and agile way (built into the structure of CPAN) of branching or evolving a given module, a way that automatically took care of authorship, copyright and and other important formalities. That is, so that every bit of work by any author (no matter the level of it's original author's involvement after it is released) would be completely shared with the other authors and users.

      Of course, this solution might not be simple (I'm pretty sure it wouldn't be (if it is possible, in the first place)), but that is precisely why I think it should be addressed in a formal and standarized (and agreed upon) way.

      Then again, one might be told to "go make your own repository if you don't like CPAN as it is". That'd be unkind response, but a valid one.

        In this sense, I feel that thought could be given to a natural and agile way (built into the structure of CPAN) of branching or evolving a given module, a way that automatically took care of authorship, copyright and and other important formalities.
        I don't think this should be build in the structure of CPAN. The ability to fork is a licensing issue - most open source licenses allows you to fork. It's totally indepent of the existance of the module on CPAN.
        That is, so that every bit of work by any author (no matter the level of it's original author's involvement after it is released) would be completely shared with the other authors and users.
        That's not the task of CPAN. CPAN should not dictate what rights authors must be willing to give up for distributing a module via CPAN. The only restrictions CPAN should put on authors are those that keep CPAN from doing its work, as such, the restrictions for authors is that their work should be freely distributable.

        Adding the requirement that outsiders may take over authorship and copyright of a module isn't a good thing in my opinion. You'll lose people contributing code to CPAN. Not to mention all the resources you have to pour in to work out the legal details of this.

        Perl --((8:>*
Re: Responsibilities of a module author
by brian_d_foy (Abbot) on Nov 23, 2005 at 18:20 UTC

    A while ago I wrote about what I considered the red herring of prerequisite problems.

    In summary: Upload everything to CPAN no matter it's readiness, but users should realize they get stuff for free. Although CPAN is not for shareware (meaning you aren't supposed to put pleas for money in the docs), I'd like to see a micro-grants program to help people pay for bug fixes.

    --
    brian d foy <brian@stonehenge.com>
    Subscribe to The Perl Review
Re: Responsibilities of a module author
by renodino (Curate) on Nov 23, 2005 at 19:29 UTC
    (For discussion purposes, I'm assuming "module authors" eq "CPAN contributors")

    Its Thanksgiving weekend here in the USA. I suggest you immerse yourself in the spirit of the holiday and simply give thanks to all the CPAN contributors, minor, major, orphaning, or otherwise. After all, they've given you the source!. If you have an issue the author won't fix, then swallow hard, fixup a version for yourself and your friends, respect the author's copyright and/or license terms (if any), and move on.

    CPAN is what it is. Accept it. If you don't like the fact that a module author doesn't snap to attention everytime you think you've found a bug, or want a new feature, TS. If you want immediate support for everything, you probably need to ditch Perl and head for VB and/or C#, and pony up the $$$/min for MSFT's 900 number. Even Linux doesn't have the kind of response you're demanding, unless you pony up $$$ for Red Hat/SUSE/etc. support contracts.

    And be thankful CPAN isn't SourceForge...now there's a real cemetary! At least everything on CPAN usually has actual, "for real and truly" code, that worked sometime, somewhere (tho I have recently seen a few modules posted with major "THIS DOESN'T WORK YET" disclaimers - not just for minor features but for the whole bundle - which seems a bit out of scope for CPAN, but what the heck...)

    As for offering remuneration, my experience indicates its pretty pointless. The amount offered is usually just a token relative to the effort. While I'm sure many CPAN contributors would like to get paid for their efforts, most are just scratching itches, or hoping for a little ego stroke, and/or maybe feel the need to give back to the community from which they've taken so much.

    Awards ? IMHO, handing out a few chachkis to a select few contributors isn't likely to make a difference.

    Ratings ? There's already some ratings on CPAN...but most people don't even bother with them. For that matter, many (most?) folks don't seem to use CPAN directly much anymore, but use PPM's from ActiveState (or elsewhere), so rating won't likely accomplish much except permitting a few cranky users to badmouth an author simply because the author rejected a patch.

    As to the suggestion for a "community branch": it would likely violate any copyrights attached to the hijacked, er, "branched" code, so you'd need to get explicit author agreement or assignment of copyright. Of course, CPAN could decide to change the posting policies to require copyright assignment so a module could be "nationalized" whenever someone bitches about not getting their pet feature patched in. At which point, I suspect a lot of CPAN contributors will be clicking the PAUSE "Delete" link shortly thereafter...I know I will. The upside, of course, is all the extra free space that will be freed up on the CPAN servers and mirrors !

    E.g., over the past year, some (very few) folks on the DBI maillists have 'turfed for some feature additions to DBI that many of us consider laughable. Under your "branching rule", the 'turfers just need to get a couple likeminded folks to complain about it, and voila! we get a "community branch" of DBI. Not a happy situation...

    One possible solution might be to create a secondary classification akin to CORE, for modules which

    • have explicitly assigned copyright from the author(s)
    • are treated much the same as CORE modules
    • but are not delivered within CORE
    (kinda like the "javax" namespace in Java).

    Asking module authors nicely for such permission to move their module into the "approved" list would likely meet with more cooperation than the "3 cranks complain and you're nationalized" rule, or enforcing a CPAN policy of "sure, you can post here, but once you do, we own it.".

    Otherwise, in direct response to the OP Subject: Responsibilities of a module author:

    • don't knowingly violate anyone else's copyright or license terms
    • graciously accept the thanks of users who've found your contribution useful
    • patiently listen to user's suggestions and bug reports, and help as best you can
    The first is the law, and the last 2 are simply good manners. Imposing more on contributors is likely to send them to the exits, or off to SourceForge or elsewhere.

      Whilst I accept that my idea has no mileage, I would like to query one thing.

      How does it "violate copyright", to branch a copy of artistic licenced code, or the various flavours of GPL licenced code?

      I was not suggesting removing the authors copyright.

      Only copying and modifying it and redistributing it, complete with all original laballing and packaging in place. Isn't that the essence of what these licences are intended to permit?

      I'm not looking for an extended legal debate here, just confirmation or correction that my basic understanding is correct?


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
        You may be right (IANAL), tho the notion of branching and redistributing wo/ an author's express consent seems a bit nefarious. Modifying for personal use, yes. Redist ? I don't know.

        However, if by branching, you mean a complete rename, so that the branched version is completely distinguishable from the original, and the original author is given appropriate credit, but dispensed of all responsibility, I suppose branching may be an acceptable solution under the artistic license. I guess I see the difference as

        Take BrowserUk's module XYZ, modify it, and repost it as XYZ with BrowserUk listed as primary developer, but wo/ BrowserUk's permission.

        vs.

        Take BrowserUk's module XYZ, modify it, rename it and post it as XYZPlus with renodino listed a primary developer, but credit given to BrowserUk for the initial development.

        Perhaps the rules are more social contract than law; guess I need to go review the Artistic license to see what the relevant conditions are.

        Update:

        I stand corrected.

        Upon review of the Artistic License, I discovered the following:

        You may otherwise modify your copy of this Package in any way, provided that you insert a prominent notice in each changed file stating how and when you changed that file, and provided that you do at least ONE of the following:

        a) place your modifications in the Public Domain or otherwise make them Freely Available, such as by posting said modifications to Usenet or an equivalent medium, or placing the modifications on a major archive site such as uunet.uu.net, or by allowing the Copyright Holder to include your modifications in the Standard Version of the Package.

        So, having used the Artistic license on all my CPAN'd modules, I have given implicit permission for anyone to change anything in them, and redistribute as they please. Indeed, one might interpret that clause as requiring the modifier to publicly redistribute the updates.

        Which I find appalling.

        No, its not because I want absolute control. In fact, I originally used the GPL, but then took the time to really read it one day and realized it didn't do what I expected, namely, I did not want to require anyone using my modules to open source everything they used it with. That should be their choice; I'm offering my software as open source, and thats my choice. To paraphrase Yoda, "Give or give not, there is no GPL."

        And I'm more than happy for someone to create a derivative work, so long as they use a different namespace and don't list me as primary developer.

        My concern is liability. If you think the little indemnifier at the bottom of the Artistic license is all you need, I suggest you go have a chat with the folks at Sony BMG...they have plenty of indemnification printed on their CDs, but that won't stop TX and CA from grinding major bucks out of them for their recent DRM stunt.

        "But I don't write malware/spyware/etc.". Great! However, by using the Artistic license, you've not only given permission to those who do write malware to pollute your code with it, but actually required them to redistribute it using your original namespace with your name as principal developer....just so long as they're kind enough to put a tiny disclaimer in some file 5 or 6 directory levels deep in the distribution. Please keep in mind that distributing, or even facilitating, malware is now a crime in many jurisdictions.

        And of course, there's the whole issue of responsibility for bugs that are inadvertantly introduced by modifiers.

        So I'll be busy this weekend, trying to find a license that provides a bit more protection, and updating my modules to reference it.

        You're suggesting that CPAN have an official way to take-away module names from authors who aren't maintaining their modules like you (and 3 of your friends) think they should (different from abandoned modules).

        Thats not something CPAN can do.

      Its Thanksgiving weekend here in the USA. I suggest you immerse yourself in the spirit of the holiday and simply give thanks to all the CPAN contributors, minor, major, orphaning, or otherwise. After all, they've given you the source!. If you have an issue the author won't fix, then swallow hard, fixup a version for yourself and your friends, respect the author's copyright and/or license terms (if any), and move on.

      Please go back and re-read the quote that got me started on this meditation. Perhaps I got off track in the meditation itself, but the issue that I find frustrating is less about CPAN contributors not fixing things when they break but about not even bothering to maintain things when others in the community offer help.

      You're absolutely right that the code is there and it can be forked off. But I don't think it helps the community (whatever that is) to proliferate module releases along the lines of Blah::Blah::Fixed. So... instead, I'm trying to spark a discussion what could be done short of that.

      In response to some specific points, I was approaching this from the standpoint of things that might encourage me, as a CPAN contributor -- by positive or negative means -- to step up the priority to fix a bug, incorporate a patch, etc. at a time when I'm not actively using a module and have a shortage of tuits. It certainly wasn't a suggestion that any of it be "imposed".

      On the money front, I'm not suggesting significant amounts like a shareware model -- if someone said "hey, if you could get that patch in there in the next week, I'd gladly buy you a drink at the next YAPC" that might well be enough for me. The idea is to explicitly recognize that asking someone to do something for you is an imposition in their busy lives -- and even a token offering can be enough to make them feel valued as opposed to put upon.

      -xdg

      Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

        I actually got to thinking about this in light of BrowserUk's mention of a "community branch". Tho I disagree with the tenor of his suggestion (i.e., just taking the module over), I think theres a germ of an idea (which has probably already been discussed somewhere around here): namely a second tier of modules below CORE, but above "whatever's on CPAN". For the sake of discussion, I'll call them Certified Modules.

        If I read your OP correctly, one of the major issues confronting developers is that organization's won't permit downloading just any old module. I know I've encountered that with a number of my customers. If it isn't CORE, then there better be a very good reason to install/upgrade it.

        So if there were some add'l level of "trust" involved, i.e., a certification, then that issue might be eased. And part of the requirement for a Certified Module is that the module author has explicitly agreed to release the module to whoever administers certification for maintenance. One can imagine many other baseline requirements (e.g., it must use the normal build/test/install make process, it must have a test suite, it must explicitly specify which versions of perl and prereq modules, and on what OS's and/or platforms, it is certified for.

        Of course, there's the little issue of funding... I doubt there's much of an opportunity for commercialization of the process, and it will cost money for all the h/w and s/w, not to mention staff to run this. But hey, if OSDL can survive, maybe there's room for another such org ?

Re: Responsibilities of a module author
by Perl Mouse (Chaplain) on Nov 23, 2005 at 20:18 UTC
    What do you think of these ideas?
    Very bad. Downvoted you for it. CPAN is just a repository. The great thing is that anyone can contribute any code to it. It's open for everyone. It isn't a country club or a sorority where you may only join if you promise to follow some protocol or to participate in charity. If you want more out of CPAN that it is now, feel free to create your own repository.

    I oppose any suggesting authors should do this, or code should behave like that or else it's not welcome on CPAN.

    Sure, your list has good points. Follow them, great. Just don't scare people off by telling them that if they don't follow your rules, they shouldn't upload on CPAN.

    Perl --((8:>*
Re: Responsibilities of a module author
by dragonchild (Archbishop) on Nov 23, 2005 at 20:48 UTC
    I just released version 0.30 of PDF::Template to CPAN. The last release prior (0.22) was over a year ago. The last new feature was over 18 months ago. Why? Because the last time I personally used PDF::Template was 18 months ago. I just now have had time to integrate the excellent changes autrijus forked on CPAN so that you can use PDF::API2 or PDFlib, as you choose.

    Plus, fixing bugs isn't as simple as that. For one thing, I took PDF::Template over with, count 'em, 2 tests. I got that number up to about 20 and the coverage went from 10% to 26% (or so). Why so poor? Well, for one thing, I didn't test my stuff back then. For another, mocking pdflib_pl is hard. By using PDF::Writer instead, it makes it a lot easier to write tests for PDF::Template.

    Of course, the problems never stop there. P::T was written against PDFlib v3. PDFlib v7 is about to be released and it will be removing a number of functions that I use to do things like load fonts. They were deprecated 2 years earlier in v5, but I wasn't keeping track. I've made a call for helpers, but I hope you'll note the number of responses. I don't have time to keep track of PDFlib changes and I don't know PDF::API2 at all. I want help with it, but no-one seems to want to help.

    What should I do?


    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
      What should I do?

      In line with the guidelines I'm offering, I'd suggest adding a similar summary like you had above to the module documentation, plus a note that you're not actively maintaining it and are looking for a co-maintainer to hand off to. That way, any prospective users are at least aware ahead of time what to expect. Plus, you'll keep your request for help with it out in front of the module users.

      -xdg

      Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

        Except, I am actively maintaining it to the best of my abilities. It's still my responsability and I will be using it for work. In addition, I want to be involved in the direction that it takes as a module I do maintain depends on it. It's never quite that simple.

        Oh, and PDF::Writer has no documentation as the API is completely random and will change every release for a while as I refactor.


        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
Re: Responsibilities of a module author
by jdhedden (Deacon) on Nov 23, 2005 at 21:04 UTC
    add negative reviews to cpanratings for modules where the author doesn't respond to bug reports in a reasonable time
    I like this, except that the CPAN rating page only has 4 rating categories:
    • Documentation
    • Interface
    • Ease of Use
    • Overall
    I'm going to contact whoever is responsible for that site at the Perl Foundation to see about adding:
    • Reliability
    • Author Support

    Remember: There's always one more bug.
Re: Responsibilities of a module author
by cog (Parson) on Nov 24, 2005 at 10:43 UTC
    I'm with PerlMouse here.

    You just can't force people like that, or you'll scare them away.

    I am a CPAN contributor. I also have a job and sometimes I even manage to have a life.

    I can tell you first hand that sometimes you have time to make changes, and sometimes it is rewarding, but sometimes you don't, and it isn't.

    And adding bad reviews to the module is not gonna solve the problem. Not for me, it's not.

    You add a bad review and you're saying a bad thing about what I made or about how I work (even though you don't even know me), so it's kind of a personal attack.

    Plus, what happens then?

    Will the bad review go away?

    Will you make a good one?

    Can you promise that?

    Can I trust you?

    It all looks like blackmailing to me, and I can tell you it wouldn't work for me.

    Co-maintainers? I'm all for it! Just find me somebody capable and interested! (in the case of modules I haven't got much time to work on)

    Not releasing if I don't have the time to work on them?

    CPAN wouldn't be half of what it is today if we all acted that way!

    How can you tell whether you'll have time?

    You can't!

    And as for the "best maintenance" awards, I don't think it would solve a damn thing. First, because I already know who'd win (and yes, those guys do deserve an award, but keep reading), and secondly, because I don't think that somebody with less known modules would manage to change his/her life or way of coding just for an award. And you know why? Because there already is an award! It's the emails users send back saying thank you. And anyway, me fixing a module that one person uses five minutes after a bug report surely wouldn't get me an award as fast as someone fixing a bug in two weeks time in a module that 90% of the users use.

    All in all, I do understand your feelings, and Ovid's, and I do share them, but sometimes we're too busy people who won't get any less busy if you try to press them like that. All you'll get is to annoy people.

    Do use your ideas as guidelines, but please, don't try to enforce them.

Re: Responsibilities of a module author
by SolidState (Scribe) on Nov 24, 2005 at 13:46 UTC
    I think this is part of the reason why some Perl authors only want to rely upon the "core" modules -- there's a minimum committment from the Perl porters to maintain it.

    Alas, even this is not true. Yeterday I spent over an hour tracking down an obscure bug in a script a fellow worker wrote. To make a long story short, the problem was in Switch, a core module. This bug was reported about 3/2004 and is not likely to be fixed anytime soon. I'm not whining here about this - I'm just pointing out that:

    1. You need to be careful when using modules, even core ones.
    2. Sometimes bugs are left alone because they are too damn hard to fix. Sad, but true :(

    A short thread on p5p starts here.

      Umm, define "core". The perldoc to Switch states "There are undoubtedly serious bugs lurking somewhere in code this funky" and then goes on at some lengths about the limitations of source filters. TheDamian (the original author) categorizes Switch as a module "...you shouldn't use in production...", because it's an experiment. Given that, it'd take some pretty serious convincing for me to use the module for anything serious(especially since the functionality it implements is otherwise available).

      Update: itub defined "core" for me, thanks :-). I missed it because Switch.pm isn't listed at the perl.5.8.7 page at search.cpan.org, though the download does contain it. Curious indeed.


      Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan
        It is "core" because it comes with the perl distribution. People tend to (sometimes mistakedly, I have found!) trust those modules as more stable and reliable than the modules that are only found on CPAN. Why is it in the core if shouldn't be used in production? I don't know, but my guess is that it was a response to all the people who complain that Perl doesn't have a switch statement.

      Under the "Limitations" section of the Switch documentation, it states,

      Due to the heuristic nature of Switch.pm's source parsing, the presence of regexes specified with raw ?...? delimiters may cause mysterious errors. The workaround is to use m?...? instead.
      That sounds like it might be an avenue to explore to help resolve your issue.

      Hope that helps.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://511185]
Approved by ww
Front-paged by planetscape
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (12)
As of 2014-07-23 14:50 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (145 votes), past polls