NYCPHP Meetup

[David Mintz]

At the PHP conference in New York last spring I remember someone asked
Rasmus a question: which is more expensive, accessing a global or defining
a constant? He said without hesitation "defining a constant." There was
silence for a couple beats, then on to the next question.

I've since wondered if that was exactly the right question. For one tihng,
the guy who asked didn't specify if he meant "...accessing a global from
inside a function." If it's cheaper to access globals PERIOD, then what do
we need constants for? OTOH if it's faster/cheaper to *access* a constant
than a global, should we use constants *whenever* you have a variable that
ain't gonna change and that you want to be globally visible? If *defining*
a constant is indeed more expensive than *reading* a global, where's the
break-even point (in other words how many times do you need to read the
constant to make it more efficient than using a global)?

Or is it such a close call that it's mostly a matter of taste and style?

My specific case here is, I want to stick some parameterized SQL
statements into an included file and avoid hard-coding table/column names
all over the place, and pull in the file and use prepare/execute when
needed. So once again, I'm thinking, should I say

$THIS_SQL = 'select * from foo where boink = ?';

or

define('THIS_SQL', 'select * from foo where boink = ?');



"When To Define A Constant" might make a nice Phundies topic.

Many TIA,

---
David Mintz
http://davidmintz.org/

        "Anybody else got a problem with Webistics?" -- Sopranos 24:17