Front page | perl.perl5.porters |
Postings from September 2011
* David Golden (xdaveg@gmail.com) [110902 12:06]:
> On Fri, Sep 2, 2011 at 7:47 AM, Mark Overmeer <mark@overmeer.net> wrote:
> There was a very real timing issue in that Jan/Feb/March is when the
> feature freeze for the next major release of Perl happens. Anything
> sweeping is unlikely to make it in at that point.
True. 90% of my work was a documentation patch. 10% were 3 different
code changes. There was a lot discussion on major changes in other
man-pages as well, at the time, so that did not trigger me.
> As a separate note, I think you did yourself a dis-service by sending
> the four patches in one because it increases the scope. If you had
> submitted just the autosplit fix patch or re-submitted that one right
> after the release of 5.14, I think it would have stood a bigger chance
> of acceptance.
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.
Do you imply that 5.15 is already in feature freeze, because it is
right after 5.14 anymore?
>> You may write documentation about everything what is *not* possible
>> with Perl, but it is kind-of useless. Removing those from the docs fits
>> better in the idea of "keeping Perl core as small as possible". And the
>> documented list of "missing" is far from complete anyway.
>
> Once documented, it should stay documented.
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.
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
> > 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?
--
Regards,
MarkOv
------------------------------------------------------------------------
Mark Overmeer MSc MARKOV Solutions
Mark@Overmeer.net solutions@overmeer.net
http://Mark.Overmeer.net http://solutions.overmeer.net
Thread Previous
|
Thread Next