note 59828 deleted from faq.languages by sobak

Note Submitter: good dot midget at gmail dot com ---- I think there's been a slight overlook within the comments about PHP's model for OOP. Firstly, I was absolutely thrilled to see the enhancements of PHP5. I've been using PHP for... gees... a long time now. But what's always been lacking has been fully implemented OOP. Now, granted, there are ways to do things like method overloading, but c`mon.... really... Now, I know the argument is that PHP is related to the web - not application development. I believe that the PHP community today suffers from this mentality. The fact of the matter is that the world is rapidly shifting towards an SOA mentality, and rich applications presented through the web. In light of this PHP should be regarded as valuable tool for application development. I would say that while PHP has tremendous strength, it equally lacks in its implementation of OOP requirements. I find that most suggested "design patterns" are weak workarounds in PHP. C# (.NET), Java -- hell even ActionScript have a fully OO implementation allowing effective implementation of recognized design patterns. Futhermore, due to PHP's lack of OO support, true collaborative team development is greatly hindered. This is particularly evidenced in the lack of strict type casting. Legit development teams rely on this to effectively lock down their interfaces, implement error handling, etc etc etc. I'm very dissappointed to see that languages (like C#), sponsored by the likes of M$ have been able to develop such mature OO languages so rapidly, while PHP remains... well... practically in the stone age. Once these issues are addressed I think we'll see more support of PHP, and less resistance to its place in the enterprise. Abstraction is a stupid thing to bicker about. How long does it really take to write a good data abstraction layer - that can be repurposed. What's more important is the capability of the language. Hopefully IBM will jump in here and kick things into high gear. Let's get rid of all the back support and compatabilities for legacy code in favor of maturing the language and increasing its value (and decreasing objections from the enterprise market)