Sometimes a Little Too Dynamic

| 4 Comments

I've written before about difficulties in parsing introduced by indirect notation in Perl 5 as well as why barewords in Perl 5 making parsing difficult.

Nicholas Clark reminded me over the weekend of something I heard long ago. In particular:

... as well as action at a distance, there's a speed hit on every class method call because first the code does a stash lookup to see if the package name string is actually a filehandle ...

— Nicholas Clark, methods and bareword file handles, action at a distance, (un)speed

That is, when invoking a method on a bareword (such as the name of a class), Perl 5 has to check whether a filehandle of that name exists, then fetch the underlying filehandle object, then invoke the method on that object. This takes place even if you never use bareword filehandles in your program. It's likely too risky to change now (at least in Perl 5) lest millions of programs written since 1994 suddenly and mysteriously break with odd error messages.

(The correct design solution is to forbid the use of ambiguous barewords at the syntax level in order to avoid costly and often unnecessary runtime checks. In other words, similar things should look similar and different things—filehandles and class names—should look different.)

4 Comments

This is worse, because many people believe prefix notation is faster.

Hm... so there might be a speed advantage in avoiding class methods and instead creating nearly empty objects to do method calls against. Sounds like a fun thing to benchmark sometime.

That reminds me a bit of JavaScript, where using a factory for all objects within a system is useful to avoid namespace collisions. Any speed gain appears modest to me, but this is an interesting demonstration of how a syntax misfeature can pessimize implementation performance.

Perhaps we could use the "no name;" syntax to allow users to enforce self deprecating features like this:

no bareword_filehandles;

I am not advocating for this syntax. I am advocating for self deprecating features. Allowing the user to remove unwanted features this way would allow us to keep language cruft out of our own code. Plus, if it became common practice, that would be good support for deprecating and then removing bareword filehandles from Perl 5.

Yours,
Tom

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

affiliated with ModernPerl.net

Categories

Pages

About this Entry

This page contains a single entry by chromatic published on June 14, 2010 4:15 PM.

The Importance of a Number was the previous entry in this blog.

Assumptions is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.


Sponsored by Blender Recipe Reviews and the Trendshare how to invest guide

Powered by the Perl programming language

what is programming?