Front page | perl.perl5.porters |
Postings from January 2011
[cc to Karl for last paragraph]
Mark Overmeer wrote:
> For about 50 functions offered by POSIX, the name is
> directly calling a CORE function with the same name.
I was looking at that myself.
> Wouldn't it be cheaper to alias the names?
Cheaper at which level? Is this merely to skip one
call frame? Is this the right kind of optimization?
> In a dozen cases, the function maps to some perl internal:
>
> sub tolower { lc($_[0]) }
> sub getpid { $$ }
But I don't believe you can do it. Here are reasons:
* You cannot set a breakpoint on an aliased function.
If you alias it using *This::foo = \&That::bar, then
you can only breakpoint That::bar, not This::foo.
* An aliased function is not prototype checked, but the
builtins are. In preceding example, That::bar may
have a prototype, but This::foo shall not.
* The CORE functions do not really live in some mythical
%CORE:: symbol table. They are a product of the lexer
alone. That means there's no function to assign to the
the right slot in the glob. For example, these are
both equally useless:
*POSIX::tolower = *CORE::lc;
*POSIX::tolower = \&CORE::lc;
> In many, many other cases where that would also be possible, we
> do simply produce an error:
> # produces error "use method IO::Handle::flush() instead"
> sub fflush { redef "IO::Handle::flush()" }
> sub strlen { unimpl "strlen() is C-specific, use length instead" }
> Does anyone understand why some functions are accepted and
> others are refused? Suggestion how to formulate this rule as
> comment in the file?
Only in a few cases. For example, what do you really think
strlen() ought to do? By POSIX definition, it gives the length
of the null-terminated string in bytes. That's a C-specific
definition that makes next to no sense in Perl.
I'd have to go through each of them to be sure they all fall
into this or some other sort of category.
> A non-breaking change for consistency would be to implement
> these functions as [well] as we can. They then change from run-
> time errors into well accepted.
Into well-accepted what?
> A seriously breaking alternative would be to degrade POSIX.pm
> into a module which only exports constants and functions which
> are not provided by the standard Perl interface (like
> ctermid()).
Why might one care to do that?
...
I do have one other matter to raise, with some trepidation:
If we're really mapping POSIX::lc() to CORE::lc(), isn't
that going to go through the full Unicode case-mapping, and
isn't that different from POSIX case-mapping? :( [*DUCKS*]
--tom
Thread Previous
|
Thread Next