Slashdot Mirror
PHP 5 OO In 24 Slides
An anonymous reader writes "At php|works about a week ago John Coggeshall gave an interesting talk on object oriented programming using PHP version 5. Even if you couldn't be at the talk, his slides are available online which gives you a pretty good idea of what you can expect from the OO model. Java programmers will be pleased."
If you bother to make slides for a presentation, and then publish them on the web, you should take the extra minute or two and run a spell check over them. Reading something that includes misspellings and grammatical errors every other sentence is not just distracting -- it makes me wonder if the content and examples are correct.
1)Its too big. With 1500 classes there's no way a developer can keep a significant chunk in his mind
In what way is a standard library of 1500 classes, all documented in the same place, harder for developers to understand than 200 different libraries each implementing 10-15 classes?
2)Its too big part 2- the bigger the library, the more bugs it has
Of course 1500 classes are likely to contain more bugs than 15 classes. But do you have any evidence that those classes are likely to be buggier as a result of being standardised, than they would have been if they'd been written by dozens of different people and never tested together?
3)Having one giant library that does 10 billion things isn't a good idea. Its better to have individual libraries written, and have more focus on those libraries by the teams.
Do you have any evidence that it's better for the teams who write these 1500 classes NOT to talk to one another, standardise their design, and test their classes together, than it is for them to collaborate?
4)It kills innovation. In languages without large standard libraries, implementations compete and only the best get common usage. With 1 standard huge library, people limp along with the standard so as not to reinvent the wheel. This means good ideas aren't followed through and written, and huge losses in productivity
This is the only one of your points that has merit, and even there it's unclear. I'll put it this way: I am more likely to use advanced functionality in a language where that functionality is standard (and therefore present on everyone's computer) than I am in one where it is not.
Concrete example: when I'm developing in Java, I use the cross-platform Swing library, because it comes with the language. When I'm developing in C#, I write the GUI with Windows.Forms, even though I know that I could be using GTK# and letting Linux users use my application. Why do I do that? Because Windows users are more numerous than Linux users, and Windows users are not willing to download ten megabytes of GTK+ runtime to run my program.
If the GUI library had been part of the actual CLR standard, then it would have been easily implementable on Linux, and the problem would not have arisen. But as the most popular GUI library for C# is NOT part of the standard library, it is not available everywhere, and Linux users suffer the consequences.
5)Backwards compatibility. When you have a standard library, those methods need to be supported forever. When its third party libraries, the third party will support them, and the language can evolve without worrying. If they aren't supported a new supported library will rise throught he competition
Which is great - until YOU find yourself wanting to use some old code that was written for a third-party library that was discontinued years ago. Small comfort that there's a new better library to frobnicate widgets, when you're faced with having to waste a month converting 200,000 lines of code to USE this new library, or installing Windows 98 on an old machine to use the only version of the old library you can find!
It comes down to this -- small standard libraries and fast-changing implementations are fine in their place, but that place is the hacker world, where people learn new APIs for fun, and rewrite all their code every day before breakfast. In the real world, where Java (and PHP) are being used, the important thing is STABILITY. We need to know that the code we write today will be reusable in five years' time. And your cool innovative evolving libraries do not even pretend to provide that guarantee.
Does it make sense to define classes, create objects, restore objects from some serialized storage or database, etc. etc. in the context of a web application? That's a lot of scaffolding to build and tear down for every HTTP request.
Yes, it does make sense. OO is a way to abstract your code and make it easier to test and re-use.
What do you mean "scaffolding"? Do you have some numbers? Benchmarks? Before/after comparisons? Creating an object is (supposed to be) a lightweight event. You probably use functions right? Put things in different files rather than one big file? Use variables? Creating objects is no worst.
If you've been programming more than a few months, you soon realize that maintainability is much more important than performance except on a few exotic projects that must of us will never work on.
The ZEND Accelerator has clever caching and compilation mechanisms, but how many people have the Accelerator installed?
Probably the people who need it?
In that environment it makes sense to keep the scripts as short and simple as possible, not add code and complexity with OOP.
Again, without benchmarks, requirements, etc., that statement is meaningless. OOP *removes* complexity if you do it right. Imagine code like this:
That's the kind of expressiveness OO gives you. Imagine you have a stable set of model and persistence classes, adding functionality is like writing pseudocode. "Performance" is not as important as being able to tell the client you can add new functionality with just a day or two of programming. IMO.In my PHP 4 projects I mainly used classes to get a namespace, not for any other OOP purposes.
Ahh, there's the problem. You're not getting enough benefits from OO to justify using it. Study some books on OO programming and design patterns and figure out how to use OO to make your code *smaller* and more powerful, you might even find a clean way to optimize your code so it's faster than it was.
I won't pretend that PHP's OO is anything but a toy, but it's amazing how much benefit can be squeezed out of it.