Front page | perl.perl5.porters |
Postings from January 2011
* Tom Christiansen (tchrist@perl.com) [110131 12:25]:
> 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?
We have more of these optimizations in modules.
>> In a dozen cases, the function maps to some perl internal:
>> sub tolower { lc($_[0]) }
>> sub getpid { $$ }
[...]
> * 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;
The cited paragraph was not about aliasing anymore. But anyway, I did
not know this. So, aliasing is not possible as optimization
> 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.
With the same flexibility as the current error "use length()", you
can implement it to use length.
> > 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?
Sorry. "into accepted calls."
> > 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?
IMO, you should either implement something perfectly or not. Certainly
for a Perl code module. The Perl functions are much smarter than the
POSIX functions, and often behave just a little differently. Not
perfectly than don't provide it. Probably deprecate the use first?
> 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*]
Just what I mean with "one-on-one mapping from POSIX to Perl" isn't
correct. The current implementation is too limited, if feasible at
all. Of course, it fitted better with "classic" Perl versions.
--
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