views:

123

answers:

4

hi, here's my question.

What are valid reasons NOT to use keywords public, private, protected in php?

The story: I've started a project with a team that actively uses access modifiers in their code (even "public" explicitly) and wants to convince me to do the same. I always find this kind of stuff totally useless in a dynamic language like php, but I realize that my gut feeling is hardly an argument in a technical discussion. Therefore I'm looking for a solid, clear explanation why access modifiers are useless (or even harmful) in php.

I'm aware that some similar topics already exist

however there are several reasons why I'm posting this one

  • I am not asking if I should use "public" or not. I'm already not using it.
  • I am explicitly not interested to hear why access modifiers are good (I know they're bad, I just need an expert to confirm that).
  • If you're about telling me about "best practices" and "principles of OOP", please do not bother.

TIA

+2  A: 

valid reasons NOT to use keywords public, private, protected in php?

Gordon
@Gordon, can you elaborate on 3). I do care about encapsulation, how exactly using "private" can help me?
stereofrog
@stereofrog No. I cannot shake the feeling that you are trying to draw me into quibble :) I am pretty sure you know I am refering to controlling access to the encapsulated state, not just the act of grouping related state into objects as such. Also, you said I should not elaborate on OO principles.
Gordon
@Gordon, I am not trying to draw you into anything. I've asked a question and wanted to hear something else than usual blahblah. Thanks for taking time!
stereofrog
@stereofrog well, what do you want to hear then? Visibility modifiers control access to encapsulated state from the outside and inherited classes, allowing for greater control over your oo design. I take you know that. If you find this a superfluous or pointless thing to do, then be it so.
Gordon
Visibility has nothing to do with the programming paradigm. There are lots of FP languages that offer modules instead of objects and visibility for "members" of that modules. Further more, Erlang allows passing of arguments to a module, which resembles a lot the way args are passed to constructors in OO languages.
Ionuț G. Stan
And I pretty much agree that visibility has not that much to do with encapsulation and information hiding.
Ionuț G. Stan
@Ionut your arguments about Erlang and other FP languages might be true (no clue), but they are not for PHP. The only paradigm you use visibility modifiers with PHP is when using OOP. I changed the last point to make it more clear.
Gordon
+3  A: 

In a dynamic language like PHP, it is assumed that the programmer knows how the code works. That means the programmer knows which methods to call and which should not be called directly.

This is similar to untyped variables: in typed languages each variable is explicitly typed, but in PHP it is assumed that the programmer knows the type of each variable.

Sjoerd
Which is only valid if every programmer working on it is responsible for the whole codebase. In larger projects, this isn't always the case.
Wrikken
In a language like PHP is far more important than in a compiled one the use of such modifiers. The programmers can read all the source code and need directions on what methods are usefull for them or just inner mechanics
Eineki
@Sjoerd: I don't get it. Assume I've got a library to work with, and a documented list of methods I'm supposed to call. Why do I need to know how exactly this library works?
stereofrog
+4  A: 

The private modifier is - imho - vastly overused. The problem with it is that it makes it impossible to extend classes. But more importantly, it is a concept that leads one to write code which is class-oriented, rather then object-oriented.

I have no beef with protected for properties. In fact, I think it should be the only scope used. protected methods are usually a hassle though, as it makes testing harder.

troelskn
I agree on keeping properties `protected` instead of `private`. As for testing private and protected methods, have a look at http://sebastian-bergmann.de/archives/881-Testing-Your-Privates.html
Gordon
@troelskn: thanks for this "class vs object-oriented" thing - have to read more about that.
stereofrog
Agreed private should probably never be used (except possibly in hardware device drivers - but does anyone write these in PHP?). But did you really mean us to infer you think 'public' should never be used?
symcbean
@symcbean Yes, properties should be `protected` - methods `public`. If you need `public` properties, you are dealing with data, not objects. Use an associative array for that.
troelskn
+1  A: 

mario nailed it (copied from the comments)

Access modifiers make sense in Java/C++ and compiled code in general, where they are enforceable. In uncompiled scripting languages they can easily be ripped out. Hence they should be considered just decorators, and thus pragmatically could just be implemented as coding convention. (See underscoritis in Python, and pretty much any other scripting language. PHP is pretty alone with its purposeless access decorators.)

You won't have much success convincing your teammates about the advantage of useful APIs over encapsulation by restrictiveness. The use of syntax-enforced access decorators is often cargo cult driven.

stereofrog
Indeed. Instead of helping the programmer at compile time, it only makes the program more likely to fail at run time.
Sjoerd
Access modifiers enforceable in C++? Since when? As far as I know, you can modify header files and you can always #define private public. Not sure how that changes the ABI for DLLs and static libraries, but it's certainly possible. In theory, you could always decompile Java class files, change private to public, and recompile. So they are not truly enforceable.
luiscubal