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...
what constants do you define?
Moderator: General Moderators
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
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...
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...
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
^^^ 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
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
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
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.Hockey wrote:Constants, in my perspective are different than a registry or config object.
(#10850)
- feyd
- Neighborhood Spidermoddy
- Posts: 31559
- Joined: Mon Mar 29, 2004 3:24 pm
- Location: Bothell, Washington, USA
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.
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.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
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???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.
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.
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
Couldn't the same be said for storing these values in variables? What is the workaround?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.
- feyd
- Neighborhood Spidermoddy
- Posts: 31559
- Joined: Mon Mar 29, 2004 3:24 pm
- Location: Bothell, Washington, USA
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.Everah wrote:Couldn't the same be said for storing these values in variables? What is the workaround?
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.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
DB settings IMHO are best stored in an XML/INI file outside the document root or at a minimim .htaccess protected randomly named directoryEverah wrote:Couldn't the same be said for storing these values in variables? What is the workaround?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.
- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
- feyd
- Neighborhood Spidermoddy
- Posts: 31559
- Joined: Mon Mar 29, 2004 3:24 pm
- Location: Bothell, Washington, USA
Bingo!Everah wrote:So does that mean that declaring a class variable as private still doesn't ensure that it cannot be recalled?feyd wrote:It's a shame that the reflection system allows retrieval of private data.
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.
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
That doesn't solve the problem of outputting them. Once parsed an ini file is simply an array of values.Hockey wrote:DB settings IMHO are best stored in an XML/INI file outside the document root or at a minimim .htaccess protected randomly named directoryEverah wrote:Couldn't the same be said for storing these values in variables? What is the workaround?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.
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.