develooper Front page | perl.perl5.porters | Postings from May 2013

[perl #117969] use POSIX emits multiple warnings if used after "Cwd"

Thread Previous
From:
Linda Walsh via RT
Date:
May 12, 2013 18:27
Subject:
[perl #117969] use POSIX emits multiple warnings if used after "Cwd"
Message ID:
rt-3.6.HEAD-2650-1368383243-1669.117969-15-0@perl.org
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=117969

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About