private constants

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

koen.h
Forum Contributor
Posts: 268
Joined: Sat May 03, 2008 8:43 am

private constants

Post 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?
User avatar
John Cartwright
Site Admin
Posts: 11470
Joined: Tue Dec 23, 2003 2:10 am
Location: Toronto
Contact:

Re: private constants

Post by John Cartwright »

I've been wondering the same thing.

//following this thread
User avatar
Eran
DevNet Master
Posts: 3549
Joined: Fri Jan 18, 2008 12:36 am
Location: Israel, ME

Re: private constants

Post by Eran »

protected static?
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: private constants

Post 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
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Re: private constants

Post 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());
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Re: private constants

Post 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.
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Re: private constants

Post 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 ;)
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Re: private constants

Post by Jenk »

Stream wrapper/model. Such as writeSomethingToStream() but the stream is private without accessor/mutator.
koen.h
Forum Contributor
Posts: 268
Joined: Sat May 03, 2008 8:43 am

Re: private constants

Post 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.
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Re: private constants

Post 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 :)
McGruff
DevNet Master
Posts: 2893
Joined: Thu Jan 30, 2003 8:26 pm
Location: Glasgow, Scotland

Re: private constants

Post by McGruff »

Wot Jenk said with knobs on.
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: private constants

Post 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.
McGruff
DevNet Master
Posts: 2893
Joined: Thu Jan 30, 2003 8:26 pm
Location: Glasgow, Scotland

Re: private constants

Post 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.
User avatar
Eran
DevNet Master
Posts: 3549
Joined: Fri Jan 18, 2008 12:36 am
Location: Israel, ME

Re: private constants

Post 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.
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: private constants

Post 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.
Post Reply