If you are just starting, PHP has insurmountable advantage over other programming languages for the webs, for reasons I already stated above. For a real big social website, the difference may not be that significant, and in fact PHP does lack certain OOP features to be called a complete OO language. In this case, you will have to decide for yourself.
Like what, for example? Or compared to what?
Well, heres a list I can think of:
- Not everything is an object, string and array for instance.
- Impossible to achieve auto-boxing/auto-unboxing.
- No nested/anonymous class support.
- C# style property accessors syntax aint implemented.
- Not supporting wildcard namespace import like Java and C#.
- Metaprogramming not available, runkits may be a solution to this?
Of course there are more, I may add them to the list later.
A programming language is Object Oriented if it satisfies 3 base principles:
- Encapsulation
- Polymorphism
- Inheritance
Since PHP does satisfy all three, it doesn’t matter what some think of how much object oriented it is or isn’t! 
In PHP every var is either an object, number, string or array. What else do you think they are? Also, not everything needs to be an object for it to be an object oriented language.
PHP has had anonymous classes for ages; they’re more for using with properties than methods though.
Is that a requirement somewhere that a language has to have C# style way of things to be qualified as an object oriented language? There were object oriented languages before there was C#.
Namespaces are a bit new in PHP, they’ll mature with time.
4 is proposed for PHP 5.6 as well
PHP has many advantages over its competitors as web development through PHP is easier, fast and economic. That,s why it is widely preferred.
I wonder what else are proposed for PHP 5.6 though. I believe Metaprogramming is needed for PHP 5.6, the others can wait till PHP 6.0. The easiest way to get it done is to simply have runkit bundled with PHP like PDO and Memcached. It should not even be difficult, as all they have to do is to improve runkit’s compatibility beyond PHP 5.3. I know runkit does not fully achieve metaprogramming, but it will help.
Does PHP need that? Why is that so urgent?
/* ======================
* 1 Read only attribute on member variables would save having to create numerous getters
*/
class Buffy { public readonly $slainVampireCount: }
/* ======================
* 2 An immutable function which throws an exception on any write attempts
* Basically a value object. But be nice to have it apply to arrays as well. Helps to make code more robust.
*/
$buffy = immutable(new Buffy('Buffy Summers', 14304));
*/
/* ======================
* Type hinting and automatic getter/setter generator for member variables?
* Already type hint for methods so why not for member variables
*
* Being able to specify standard getter/setters will drastically reduce boiler plate code as well as documentation annotations
* Bonus points if type safe arrays can be handled as well
*/
class Buffy {
private Address $address : get; // Functions as though getAddress() available
private Person $fans: array, add} // Collection with $fans->add(Person $person) available
/* ======================
* Type hinting return values
* Mostly for documentation but still handy
*/
function Person getGreatestVampireSlayerEver() { return new Person('Buffy'); }
None of these are actually required or urgent but I think they would improve the quality of code and not be all that difficult to implement.
Yes PHP needs that, it makes plugin system so much easier to design.
I carefully agree with you too @Hall_of_Famer ;
Personally, I think the lack of return types cripples PHP’s OOP opportunities on a very high level. You can’t adequately utilize Interfaces without a bit of concern. If I could tell my Interface, the type it should return for each method, that would give me the comfort knowing that a class that implements that interface will return an expected type. Today, that isn’t the case, it could implement the parameters of the method, but return a completely different object.
My work is big on the need for interfaces (they are a big part of API design), DI can use them for further extensible opportunities too, but without return types, it makes it difficult to fully trust them.
Read-Only can “kind of” be implemented now, just create a private variable in your object and a public getter method, but having a readonly attribute would be a “nice to have”.
For auto boxing/unboxing, I can see the usefulness, but at the same time, I think readability is sometimes better knowing you have to ask to do it.
Having everything be an object would be nice, though I’m not sure it is absolutely necessary. Granted the biggest limitation it has right now is you can’t extend a string since it isn’t an object (you’d actually have to recreate it).
If you want a read-only variable, use const.
For getters/setters, you can use the magic methods __get() and __set(). Or, define your own functions. Or, make the variables public and access them through the object.
class thing {
public $attribute=null;
}
$newthing = new thing();
$newthing->attribute='blue';
echo $newthing->attribute;
If you want documentation to appear, use PHPdoc syntax, which can be parsed in most IDEs that supports PHP.
/**
* function description here
* @param string $input some comments here
* @return string some comments here
*/
function testme($input){
return $input;
}
I think some of this boils down to partly unfamiliarity with PHP and partly wanting it to be something it is not.
You have to define a const with class definition and its value can’t be changed. Read-only on the other hand can be set in a method (its rw within the class) but is read-only when accessed outside the class. That would definitely bring down the usage of getters.
Good point. Also const does not accept arrays or objects, it only works for numbers, booleans and strings.
Off Topic:
To help keep the other thread on topic, I’ve split the discussion around PHP’s OOP to a new thread as I believe this to be a worthwhile discussion.
The problem with doing everything by magic such as __get , __set and __call is that unless the @property/@method phpdoc is set they are a really ugly way to define public interfaces. Properties are a halfway house between the verbosity of getters/setters and the innocuous allure of seemingly easy to use __get __set approach( they are easy to use only when fresh in mind if they do not have doc annotation created by the original creator to show their intention ).
Wanting it to be “something it is not” is one of those big issues, if you read php internals you will see it is very fractured with 3 quite distinct mind sets all with different view points of what it is and what it should be.
- Procedural bias - some even would like a PHP without classes.
- It should be forever newbie friendly and not be chosen for bigger projects( though when doing a projects outside of boutique work how can this be calculated? Don’t pick the language unless it has a fixed termination and will delete itself at said time as a guarantee? ). This mentality gets a lot of things nos when voting. Also there seems to be a lot of bad experience of Java so anything even smelling of java gets a no. Java can be very productive, more productive than PHP with the right tooling and you have the other JVM languages like scala, groovy and kotlin etc which have some very interesting clean approaches.
- Those that look at how current competing languages are evolving and see if those methodologies can help keep php a competetive language in the larger scale of things. Even though this is split up into two groups, those who want a more dynamic less contractual language like ruby with monkey patching etc and those who want an optionally stricter language with clear self regulating call chains( typed return etc) when desired.
If a language does not continually evolve to a standard greater than it is then programming in it is a dead end and that language is something to be outgrown of and left ASAP as a professional career path as it is a path to unfulfilling future employment, if employment can even be found in 15 years etc. Gotta play the long game keeping approaches and technologies current as there are a lot of unemployed IT people due to their physical age and non current experience.
I remember very clearly when PHP as a language was a laughing stock on the quality front and you would not necessarily get a lot of respect as a developer for doing it. There are some very good key figures who have pushed this along literally fighting for good changes. Major language changes need 66% approval and that approval is very hard fought for, it definitely is not a glee club.
Oops whats wrong with this thread? I dont recall starting this topic myself? o_o
Edit: I see, but I merely said PHP’s OOP is not complete as its missing some OO features, and thus cannot be called a complete object oriented language. For whatever they have implemented so far, I quite like them. XD
[ot]Thread title updated to reflect that better
I just didn’t want to distract the other thread from its’ original purpose with this discussion which has picked up pace over the past day. I also feel this discussion has been very good so far with a lot of discussions happening from both sides, so I wanted it to have the topic to itself.[/ot]
I agree with cpradio about the return values on interfaces. It’s one of the biggest things about php that annoys me. That, and the fact that it’s weakly typed, are two of my biggest personal gripes.
I see, it makes perfect sense, although after splitting the thread the other one seems to be dead. XD
- Procedural bias - some even would like a PHP without classes.
I dont really quite get what you are saying, are there really people who prefer PHP without classes/objects? Thats complete nonsense if they seriously believe PHP is better off as a pure procedural language lol.
And in terms of return value on interfaces, it can be a bit problematic for a dynamically typed language. I wonder if Python or Ruby has found ways to resolve this problem? Or is this a universal problem for all dynamically typed languages?