Page 1 of 3
private constants
Posted: Sun Jan 04, 2009 3:49 pm
by koen.h
I think it's a pity we don't have them in PHP. Private because I would like to restrict what other objects can do with constants. Many times they don't need to have access to them, and if it is not meant for them to have access we make it private. I also would not wan't to have other objects creating dependencies this way.
How do you people deal with this?
Re: private constants
Posted: Sun Jan 04, 2009 4:24 pm
by John Cartwright
I've been wondering the same thing.
//following this thread
Re: private constants
Posted: Sun Jan 04, 2009 4:30 pm
by Eran
protected static?
Re: private constants
Posted: Sun Jan 04, 2009 4:55 pm
by alex.barylski
I think it's a pity we don't have them in PHP. Private because I would like to restrict what other objects can do with constants. Many times they don't need to have access to them, and if it is not meant for them to have access we make it private. I also would not wan't to have other objects creating dependencies this way.
IMHO it doesn't really make sense and it would be just one more check the Zend engine would have to perform during execution.
Besides, access control modifiers are intended to restrict access to methods or member data to prevent a client developer from inadvertently manipulating the object.
Who cares if they have access to a constant, they cannot change it nor set it so there are no inadvertent side effects.
If you don't want client developers to know about the constant, maybe leave it out of the documentation?
Cheers,
Alex
Re: private constants
Posted: Mon Jan 05, 2009 12:02 am
by Chris Corbyn
Protected static doesn't have the same effect. We'd need "final" on properties before that would constitute a constant (like Java).
Unfortunately PHP only supports "final" on methods, not on properties. I doubt they'll add it neither since it would probably be an expensive addition!
I'd like final static variable too so that I can refer to pre-built objects like constants:
Code: Select all
$document->setEncoding(Encoding::$QUOTED_PRINTABLE);
Where $QUOTED_PRINTABLE is a final variable containing an object that handles that type of encoding.
Pretty much PHP will never do this I dare say. Maybe in PHP 9
EDIT | A suitable workaround is to use static methods:
Code: Select all
$document->setEncoding(Encoding::QUOTED_PRINTABLE());
Re: private constants
Posted: Mon Jan 05, 2009 4:42 am
by Jenk
Is it really worth making anything private, be it a constant, a method, or property? The best, yet still not convincing argument, is that it is not part of the class/objects interface, and thus should not be used by anything outside of that object, but why is it there in the first place, if it is not to be accessed? Why must you completely restrict access? How can you be so certain that you won't want to override, or allow access in the future? (To prevent unnecessary discussion on this point, you can't. No, really, you can't.)
I was quite fond of making as much as I could private (i.e. anything not in the designed interface) but after getting nothing but headaches from this when testing, or having to refactor robust classes just so I could override or extend, I came to realise there is no benefit, only hindrance.
Re: private constants
Posted: Mon Jan 05, 2009 5:35 am
by Chris Corbyn
I agree with you in part, but making things private clarifies intent.
Also, if having things private hinders testing, there's something going wrong what your tests. I'd need to see an example of where your tests need access to private members before I could accept that one

Re: private constants
Posted: Mon Jan 05, 2009 6:51 am
by Jenk
Stream wrapper/model. Such as writeSomethingToStream() but the stream is private without accessor/mutator.
Re: private constants
Posted: Mon Jan 05, 2009 12:27 pm
by koen.h
Jenk wrote:but why is it there in the first place, if it is not to be accessed?
They are to be accessed, but in this case only by the object itself.
The difference in opinions here probably stems from differences in opinion on the correct usage of class constants.
Re: private constants
Posted: Mon Jan 05, 2009 7:53 pm
by Chris Corbyn
Jenk wrote:Stream wrapper/model. Such as writeSomethingToStream() but the stream is private without accessor/mutator.
Genuinely curious
Can you post your test case where you would need access to the private member? I'd like to see if there's a better way to do this, keeping the "private" members private.
If the StreamWrapper is a wrapper then I'd assume you provide the target stream to the wrapper?
Code: Select all
interface Stream {
function read($length = 8192);
function write($bytes);
}
class StreamWrapper {
function __construct(Stream $stream) {
}
function writeSomethingToStream() {
}
}
Maybe I've misunderstood what your stream wrapper does, so I'd like to see a test case

Re: private constants
Posted: Mon Jan 05, 2009 10:41 pm
by McGruff
Wot Jenk said
with knobs on.
Re: private constants
Posted: Tue Jan 06, 2009 1:44 am
by josh
At first glance it sounds reasonable. Non-public methods must not be called by external clients and therefore safeguards must be put in place to prevent this. In fact this is an entirely imaginary problem. Consider a normal house with doors and windows. How often would visitors try to climb in through a window rather than ring the doorbell? Setting bear traps beneath the former will be wasted effort.
Consider the fact this is an incomplete analogy & logical fallacy, how often would visitors try to call tech support to operate the door? They *do* do something, they prevent errors. They are good practice for the same reason doing TDD is good practice. A better question to ask is, why in gods name would you want to fill your brain with useless remembered facts about which methods to call, etc.. etc.. I find when I'm really hammering out code I'll write a class and refer to its test case 30 minutes later to refresh my memory. Protected methods are a safe guard. It's like saying why wear a seat belt, I'm not going to crash intentionally? Well $h17 happens out here in the real world unfortunately, so I'll take as much security as I can get. If you want to override stuff use protected not private.
Yeah I do TDD, I write a test and then I write a public method for the interface, then I write sometimes 10+ protected template / other methods that work together to solve the problem. So yes I need a way to keep track of which ones are callable.
Its not needed because of naming convention? SO in that logic protected is just another naming convention anyways, and therefore no different then underscores. Oh yeah except that the compiler recognizes them.
Re: private constants
Posted: Tue Jan 06, 2009 2:26 am
by McGruff
jshpro2 wrote:Well $h17 happens out here in the real world unfortunately
I've never had a problem mistaking windows for doors and I've never seen anyone else do this. Not once. Ever. Why a problem which never occurs should be widely perceived as a real issue is a fascinating study in psychology. The mind is vulnerable to certain kinds of logic-slaying memes, weak points where reason gets blurred and nonsense pours in.
There's lots of things you might do but won't: stick your fingers in a live electrical socket, eat soup with a comb, go fishing with a spanner, etc, but you don't need protection. Why not? Because you will, in fact, recognise the interface.
After that it's just a labelling issue. I'd prefer something more terse.
Re: private constants
Posted: Tue Jan 06, 2009 2:36 am
by Eran
Visibility is an important OO feature, not a labeling scheme. The point is to convey intended use and black-box approach instead of a whitebox approach which could create unwanted dependencies that at the time seemed like easier solutions. Designing against visibility is more difficult, but rewards the developer as complexity keeps increasing.
Re: private constants
Posted: Tue Jan 06, 2009 3:34 am
by josh
Well again my point is we're talking about software not windows and doors. Obviously most people don't have problems using their door, but it would seem a lot of people do with software, go figure. Maybe its because software != houses. It is obvious not to use the window because we recognize it, we've seen a million windows and doors before, but with software most people that haven't seen your code aren't going to recognize a X from a Z, thats where explicitness / semantics comes in. And with private/public if the user still doesn't understand, based on labelling, the compiler will stop him from continuing. Seeing as its optional I see no problem with how the language currently works, if you're too lazy to type it noones stopping you, but it _is_ a beneficial language feature.