private constants
Moderator: General Moderators
private constants
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?
How do you people deal with this?
- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact:
Re: private constants
I've been wondering the same thing.
//following this thread
//following this thread
Re: private constants
protected static?
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: private constants
IMHO it doesn't really make sense and it would be just one more check the Zend engine would have to perform during execution.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.
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
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
Re: private constants
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:
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:
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);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
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.
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.
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
Re: private constants
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
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
Stream wrapper/model. Such as writeSomethingToStream() but the stream is private without accessor/mutator.
Re: private constants
They are to be accessed, but in this case only by the object itself.Jenk wrote:but why is it there in the first place, if it is not to be accessed?
The difference in opinions here probably stems from differences in opinion on the correct usage of class constants.
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
Re: private constants
Genuinely curiousJenk wrote:Stream wrapper/model. Such as writeSomethingToStream() but the stream is private without accessor/mutator.
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() {
}
}
Re: private constants
Wot Jenk said with knobs on.
Re: private constants
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.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.
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
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.jshpro2 wrote:Well $h17 happens out here in the real world unfortunately
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
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
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.