Front page | perl.perl5.porters |
Postings from May 2013
On Sun May 12 10:31:53 2013, nicholas wrote: > On Sun, May 12, 2013 at 10:10:49AM -0700, Linda Walsh via RT wrote: > > The idea that that the POSIX module would blindly redefine common > > functions is entirely a short-coming in the POSIX module. > > Depends on one's idea of common. Both modules are *documented* as > defining > a routine with the same name, and, as it turns out, both have exported > it > by default since 5.000. --- Acknowledged. > No, it is doing exactly what you asked it to do - by default it > exports > everything. It happens that the two modules have conflicting exports. > This will not be the only case of it. --- ??? I didn't quite parse that -- are you saying I should have seen other warnings or did you mean that by default, POSIX exports .. over 500 names is likely to cause problems? > > > Should I report the 20-score or more cases where it does work as > bugs? > > Depends if they are actually bugs. This is working as documented. That > it's > documented behaviour is not what you want or expect is *not* a bug. ---- Documented behavior of bad behavior doesn't mean it is desirable behavior or that it shouldn't be improved. In the case of the ones that work -- I wouldn't be strongly motivated to report them as problems regardless of whether or not they were as they are doing what the user "means", not adhering to some bad behavior and relying on it being documented as an excuse for trying to fix a bad design. Also, it isn't 'really' a inteface to IEEE Std 1003.1. If it was, it would return the inode w/the name in "readdir" as POSIX specifies. > > The fact that it stomps on namespace and issues warnings for things > as > > it overwrites things that have not been explicitly imported seems an > > unfriendly default for a CORE module, no? > > Possibly, but this behaviour has existed for the past 18.5 years. It's > not going to change now. --- This is IMO, a major reason why perl usage is declining and is unlikely to survive. It's maintainers refuse to allow adaptation to changing conditions and standard and actively work to silence people who try to change this status quo. It's not that I am supporting unbridled change either -- to the contrary, I'm seen as *conservative* on the SuSE list in not supporting the wholesale teardown of past compatibility for the sake of mandating exclusive use of new features. I.e. I want forward progress, but am a strong proponent of preserving compatibility or automatic upgrades. > I am going to mark this bug as rejected. --- Sadly, Vim has responded with it's new feature list -- to go with python RE's and integration with perl's votes falling behind almost 8:1. This wasn't true 5 years ago... Not allowing this as a request for upgrading the POSIX interface to today's perl standards -- where exporting 500+ symbols by default would be considered "bad practice", seems like you really want to see perl gain the reputation as one of those dinosaur languages like Cobol... I do not relish that future. I like perl, but I don't like how it is ossifying. --- via perlbug: queue: perl5 status: rejected https://rt.perl.org:443/rt3/Ticket/Display.html?id=117969Thread Previous