develooper Front page | perl.perl5.porters | Postings from January 2011

Re: Time to update

Thread Previous | Thread Next
Tom Christiansen
January 31, 2011 04:24
Re: Time to update
Message ID:
[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
> 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*]


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About