Page 3 of 4
Posted: Fri Sep 22, 2006 2:15 pm
by Maugrim_The_Reaper
You're putting words in my mouth, Hockey.
Constants are immutable, but they can also create unreported dependencies (coupling) like Globals do since they are essentially not documented in a class interface/API - they just get used without entry point. Unless the constant is namespaced (specific to the Interface of a class) it's just hanging out there for any class to pick and use. In OOP, a Config object is a safer bet. Sorry if my short comment was a bit vague on the similarity to Globals...
Posted: Fri Sep 22, 2006 3:38 pm
by alex.barylski
^^^ Ok you have me there
But doing what feyd showed wasn't exactly the impression I was under. It sounded like people were advocating using a config objet as a relpacement for CONSTANTS, which IMHO isn't right.
Constants, in my perspective are different than a registry or config object. That was the point I was trying to make. Nothing more, nothing less.
Although I would argue that a namespace for a constant isn't really needed, although I admit it makes for clearer code. Constants once set, are basically (should be) set in stone and *never* change.
So really, there is technically little harm that can come of using a global constant, outside of namespace collisions I guess. Which would no doubt be annoying if all the cool names were taken, but easily rectifified by making a new name. That is, assuming PHP informs you a constant by that name already exists, if it doesn't, then I just put my foot in my mouth.
Cheers

Posted: Fri Sep 22, 2006 3:56 pm
by Christopher
Hockey wrote:Constants, in my perspective are different than a registry or config object.
I don't think anyone disagrees that they are different. The point is they both serve the same purpose. Given that the serve the same purpose then you have a choice of implementations. An implementation without globals is considered superior for the reasons mentioned.
Posted: Fri Sep 22, 2006 4:00 pm
by feyd
It will alert you of a redefinition, but it won't let you use anything but scalar values. Granted, that is just about all that should ever go into a constant, but there are times when an array or something else could be useful, but I can understand.
The example I posted is most akin to a C/C++ enum, although a little different. I don't like constants on the whole (in PHP.) Constant stuff that is absolutely constant, but leave variable things to other storage media.
Posted: Fri Sep 22, 2006 4:13 pm
by alex.barylski
feyd wrote:It will alert you of a redefinition, but it won't let you use anything but scalar values. Granted, that is just about all that should ever go into a constant, but there are times when an array or something else could be useful, but I can understand.
The example I posted is most akin to a C/C++ enum, although a little different. I don't like constants on the whole (in
PHP.) Constant stuff that is absolutely constant, but leave variable things to other storage media.
I agree feyd, but that was the point I was trying to make, that there are indeed times where constants should be constant. Is it just me or am I horrible at articulating my perspective in general???
Arborint: I agree, but I wasn't arguing that a registry is better or worse than a global, I was saying that constants serve a purpose and registry or config objects are not a substitute for const-ness when it makes sense.

Posted: Sat Sep 23, 2006 6:27 am
by Ree
I use constants to define file system paths and db credentials. I don't think anyone can persuade me to put these settings in an INI or XML.

Posted: Sat Sep 23, 2006 6:38 am
by Maugrim_The_Reaper
Simple - if it's data which may change, it can't be a constant

. Check a dictionary for the definition of "constant".
Posted: Sat Sep 23, 2006 9:21 am
by feyd
Database credentials as constants is a potential security hole. Inserting code after the definition can easily expose them and you have no control over their exposure.
The same could be said for system pathing as exposing your server path can lead to compromises of security too.
Posted: Sat Sep 23, 2006 9:28 am
by RobertGonzalez
feyd wrote:Database credentials as constants is a potential security hole. Inserting code after the definition can easily expose them and you have no control over their exposure.
The same could be said for system pathing as exposing your server path can lead to compromises of security too.
Couldn't the same be said for storing these values in variables? What is the workaround?
Posted: Sat Sep 23, 2006 10:10 am
by feyd
Everah wrote:Couldn't the same be said for storing these values in variables? What is the workaround?
Variables can be unset(). In general, the workaround is don't use constants for security related data and unset() variables that you don't need anymore.
I personally don't like storing database credentials in variables, but it often is a necessary evil for ease of use by others. This is the reason I use privates in classes for their storage where possible. It's a shame that the reflection system allows retrieval of private data.
Posted: Sat Sep 23, 2006 10:54 am
by alex.barylski
Maugrim_The_Reaper wrote:Simple - if it's data which may change, it can't be a constant

. Check a dictionary for the definition of "constant".
Isn't that what I've been saying?

For the record...I agree with this statement

Posted: Sat Sep 23, 2006 10:57 am
by alex.barylski
Everah wrote:feyd wrote:Database credentials as constants is a potential security hole. Inserting code after the definition can easily expose them and you have no control over their exposure.
The same could be said for system pathing as exposing your server path can lead to compromises of security too.
Couldn't the same be said for storing these values in variables? What is the workaround?
DB settings IMHO are best stored in an XML/INI file outside the document root or at a minimim .htaccess protected randomly named directory

Posted: Sat Sep 23, 2006 11:05 am
by RobertGonzalez
feyd wrote:It's a shame that the reflection system allows retrieval of private data.
So does that mean that declaring a class variable as private still doesn't ensure that it cannot be recalled?
Posted: Sat Sep 23, 2006 11:10 am
by feyd
Everah wrote:feyd wrote:It's a shame that the reflection system allows retrieval of private data.
So does that mean that declaring a class variable as private still doesn't ensure that it cannot be recalled?
Bingo!
As you may recall Ole (I believe it was) wanted to get access to a private inside his unit test. Guess what, through reflection PHP allows it; which drives me nuts.
Posted: Sat Sep 23, 2006 11:18 am
by Chris Corbyn
Hockey wrote:Everah wrote:feyd wrote:Database credentials as constants is a potential security hole. Inserting code after the definition can easily expose them and you have no control over their exposure.
The same could be said for system pathing as exposing your server path can lead to compromises of security too.
Couldn't the same be said for storing these values in variables? What is the workaround?
DB settings IMHO are best stored in an XML/INI file outside the document root or at a minimim .htaccess protected randomly named directory

That doesn't solve the problem of outputting them. Once parsed an ini file is simply an array of values.
Here's my lack on knowledge on reflection here....
In JavaScript you can tell what class/function called a particular class contructor. Can this be done in PHP5? If that can be done you could use a config object that is only permitted to be used in certain locations... that's not overly scalable however.
EDIT Actually, some magic with debug_backtrace() could help there.