Front page | perl.perl5.porters |
Postings from September 2011
Re: The future of POSIX in core
Thread Previous
|
Thread Next
From:
David Golden
Date:
September 2, 2011 06:23
Subject:
Re: The future of POSIX in core
Message ID:
CAOeq1c9T3-8vRRWie8o+TU_GwyxBhoXe4NaNMQKeji9NfXY0cA@mail.gmail.com
On Fri, Sep 2, 2011 at 8:59 AM, Mark Overmeer <mark@overmeer.net> wrote:
> If someone, like me, contributes something which in a way you would
> like to see differently, then you can tell the person at that time
> but not blame him six month later. But I have discussed this already
> quite extensively with Jesse after the first three month of silence.
> And we drank beer (water) at YAPC::EU.
I agree and I'm sorry that I missed it the first time around.
Personally, I tend to be most responsive to patches in the month that
I'm volunteering to be release manager and other times it's based on
how many tuits I have or whether things impact code that I maintain.
> Do you imply that 5.15 is already in feature freeze, because it is
> right after 5.14 anymore?
No. What I meant is that Jesse declares feature-freeze and then
user-visible change freeze in the blead branch in the months leading
up to the next stable release. Then after the stable release (e.g.
5.14 in May), blead becomes open for more extensive changes (in the
5.15.X series). Next Feb or so, 5.15 will go into feature freeze in
preparation for 5.16.
> It can be documented as this: (little sarcasm intended)
>
> =head2 Not implemented
>
> Up to version 1.20 of POSIX.pm, the following functions were documented
> as "not implemented" and croaked when called. They are still not
> implemented and will never get implemented in this module.
>
> atexit atof atoi atol bsearch calloc div execl execle execlp
> execv execve execvp fprintf fputc fputs fread free freopen
> fscanf fwrite labs ldiv longjmp malloc memchr memcmp memcpy
> memmove memset offsetof putc putchar puts qsort rand realloc
> scanf setjmp siglongjmp sigsetjmp srand sscanf strcat strchr
> strcmp strcpy strcspn strlen strncat strncmp strncpy strpbrk
> strrchr strspn strtok vfprintf vprintf vsprintf
>
> The following functions croaked while pointing you to implementations
> with the same name:
>
> clearerr fclose fdopen feof ferror fflush fgetc fgetpos fgets
> fileno fopen fseek fsetpos fsync ftell setbuf setvbuf tmpfile
> ungetc
>
> But there are about 800 more functions in POSIX which are also not
> implemented in POSIX.pm but never implemented to croak nor documented
> in this manual-page. Therefore not listed here. They also do not work.
s/(800 more functions in) POSIX/$1 the POSIX standard/
> You may take a look at POSIX::2008 whether there are ways to achieve
> the desired functionality.
>
> =head2 Avoidable wrappers
>
> The following functions are exported by POSIX.pm, but are simply
> calling a function with the same name from CORE. The only (and major)
> difference between the exported function and the version in CORE, is
> that these POSIX versions do not have a prototype on them.
>
> Provided CORE function wrappers without prototype:
>
> abs alarm atan2 chdir chmod chown closedir cos exit exp
> fcntl fork getc getgrgid getgrnam getlogin getpgrp getppid
> getpwnam getpwuid gmtime link localtime log mkdir readdir
> rename rewinddir rmdir sin sprintf sqrt stat system time
> umask unlink wait waitpid
>
> Please do not use them for new code, because it will confuse other
> programmers who do expect prototypes on those functions.
>
> Useful? Not really. Possible to add? Of course
No, actually, I think that's a great rewrite. It's clear, direct and concise.
>> > program 1:
>> > use POSIX 'exit';
>> > exit @rc;
>> >
>> > program 2:
>> > exit @rc;
>> >
>> > I consider the situation a bug, in both cases, because the documentation
>> > says that exit needs a scalar. But those bugs may show up with people.
>>
>> Ugh. I'm on the fence about this sort of change.
>
> So, +1 to the guys who do not see this as a user-bug. Every opinion
> counts.
>
> Once we added prototypes to CORE::, but forgot to add them to the
> same functions in POSIX.pm. Is that a bug or a feature?
I think prototypes are a design bug.
If POSIX.pm failed to get prototypes when CORE:: got prototypes, I'm
supporting of fixing that bug. Particularly where the docs say "is
identical to the builtin", I think we can add the prototypes.
I'm on the fence about not actually doing an import, since presumably,
once imported, one could locally override the POSIX function. E.g.
$ perl -MPOSIX=chdir -wE 'local *POSIX::chdir=sub {die}; chdir "/"'
Died at -e line 1.
So making the import a no-op isn't the same thing.
-- David
Thread Previous
|
Thread Next