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."

Comments

Error on slide 5

[Anonymous Coward]

From slide 5:

Member methods may also be declared final, preventing them specifically from being overloaded in a sub class

s/overloaded/overridden/

See here.

Re:Error on slide 5

[ShecoDu]

I'm not an OOP expert, but I've always thought that the ability of having two or more methods with the same name was called overloading (I did learn that from some C++'s manuals/help files)

That URL says override but it's just a point of view, the real name is method overloading. AFAIK.

google "php method overloading" returns 35,000 links.
google "php method overriding" returns 16,000 links

Re:Error on slide 5

[Smallpond]

I think AC is correct:

PHP 5 introduces the "final" keyword to declare final members and methods. Methods and members declared final cannot be overridden by sub-classes.

overload has a specific meaning.

Re:Error on slide 5

[CaptainPinko]

All your Googling shows is that one is discussed more often than the other. Also, it could also be that the public-at-large missuses a technical term. Sorry but you haven't proven anything.

Re:Jave programmers pleased?

[Anonymous Coward]

The only languages with semi-decent OO are ones with multimethods/generic functions e.g. Common Lisp.

Oh great. A Lisp zealot and an OO zealot all in one person. Such will probably trigger a singularity and end civalization. Much more toxic than even the mod points I am surely about to receive.

Re:PHP isn't bad

[lphuberdeau]

It really depends on what you are trying to achieve but I used PHP CLI many times to solve quick problems. PHP's impressive function library makes it easy to do anything. Can you give me an example where PHP isn't suitable for general scripting?

BTW, I agree PHP is better at web than scripting. Now back to the main topic...

As always, Coggle (I just need to spread John's 'short' name) used his PHP girls in the slides.

These are far from being the first slides about PHP 5 available. I had seen some from Zeev Suraski 1.5 year ago. Actually, about every PHP conference around the world ever since PHP5 was buildable had it's set of PHP5 slides.

history of PHP OO?

[the quick brown fox]

I'd like to hear more about who designed the OO features of PHP 4, and who (re)designed them for PHP 5.

As many times as I've heard this fun fact, it never ceases to amaze me: "In ZE / PHP 4 objects weren't references, so when they were passed to a function a copy was made."

I've never heard this one before, and it's just as ridiculous: "In PHP 4, you couldn't access a member function or properity indirectly through another object's member function or properity.."

Yikes. How did they get it that wrong!?? And how did they manage to come up with (what looks like) a very reasonable object system for PHP 5?

Also, what is the "interface" feature for, if the language is not statically typed? Will you get a runtime error as soon as an implementing but non-conforming class is defined? Or is it primarily just a more formal way of documenting your class? Or does it work solely in concert with type hinting to prevent you from passing in an incorrect type?

Re:history of PHP OO?

[JabberWokky]

PHP4's OO features were pretty much a late cycle hack. PHP5's OO was thought out early and carefully designed.

If anything, the fact that PHP4's OO features worked as well as they did was impressive. The fact that they were limited was due to the point at which they were implemented. If anything, it illustrates the need to plan features early in the development cycle.

--
Evan

Re:history of PHP OO?

[wtd]

This has been my biggest problem with PHP's OO model. As good as they make it, very few people are going to use it.

Those who know enough to use it know that when it comes to web development with a bent towards obect-orientation there are far more pleasant (syntactically and/or semantically) alternatives.

Those who don't know the benefits of such an approach will see the huge library of built-in functions and think that must be the way to do things.

They would have been better off delaying the final release of PHP5 a year or two and just going through and converting the entire library to an OO model. That would be a step in the right direction.

Re:history of PHP OO?

[kris]

I'd like to hear more about who designed the OO features of PHP 4, and who (re)designed them for PHP 5.

PHP 3 was a procedural language and designed as such. Rasmus made it that way, and when you look at the code for php.net, or other code Rasmus made or approved, you'll see that he has a case and a reason for all this.

PHP 3 had so called classes and objects, which were just a fancy syntax for hashes of values and functions, added as a midnight hack by Zeev and Andi to the language. Also, that hack was severely buggy. I ought to know, because I tried to use it in implementing PHPLIB at that time, and filed over 60 bug reports against PHP 3 during the six release candidates for it.

PHP 4 tried to extend PHP 3's object capabilities, but that extension was driven mostly by Zeev, who admittedly had little knowledge of or interest in OO. Also, he tried to model PHP 4's OO capabilities with the image of C++ in mind. During the PHP 4 lifecycle, I tried several times to nudge Zeev and the PHP community into the direction of Smalltalk and Objective-C, which provide an object model that is much better suited to a scripting language than C++'s model, and also is much more expressive, but my efforts were late and since I decided not to code to the Zend engine itself, somewhat fruitless.

Zend, especially Zeev, did do his homework for the version 5 release, though, and redesigned all things OO from ground up. He did so in front of a backdrop of PHP being used more and more in off-web usecases, that is, PHP 4 slowly becoming a mainstream language leaving its little specialized corner of web applications. Zeev's idea was to provide the version 5 release of the capabilities that are needed for PHP to become a real scripting language that can be used in larger projects, without breaking to much backward compatibility, and with keeping the dynamic "scripting" capabilities and feel of the language.

He succeeded superbly - PHP 5 provides the OO you need, and enables you to operate more within the mindset of a Smalltalk or Objective-C programmer than within the mindset of a Simular or C++ programmer. In PHP 5, objects are dynamically typed (class is a property of the object, not a property of the variable name), completely self-descriptive, and capable of delegation, emulation and posing.

Try it out and do not let the syntax deceive you - this is not a C++ or Java like language, try Smalltalk and ObjC for size.

Re:history of PHP OO?

[the quick brown fox]

That was awesome, thanks!

Except for the interfaces and final features, PHP 5 OO looks a lot like that of Ruby (or Python, but more Ruby). Am I right? And I don't know what you mean by "delegation, emulation, posing". (Although I'm guessing _get, _set, and _call have to do with at least one of them.)

I don't have a problem with non-OO languages; I'm not an OO purist. But I do think if you're going to add support for a programming paradigm to your language, you should not design it in such a way that it's incredibly unintuitive and dangerous (thinking specifically of pass-by-copy here).

I think PHP 3/4 would have been much better off without the hacked in OO. One look at it made me write off the whole language (as did the lack of exception handling). Even seeing all the nice improvements in PHP 5, I still can't help but feel a little uneasy about betting my code on a language whose designers had shown themselves capable of committing some pretty egregious mistakes. Conversely, most Rubyists and Pythoners I have come into contact with have a lot of faith in the future of their languages, due in large part to their faith in Matz and Guido.

I say this not to be a jerk, but because I know a lot of developers who feel the same way, and would love to be convinced that these guys have matured as language designers to the point that they deserve to be trusted. For all its faults, PHP is still by far the web scripting language most widely supported by web hosting services.

Re:history of PHP OO?

[kris]

I know neither Ruby nor Python, so I can't tell.

And I don't know what you mean by "delegation, emulation, posing". (Although I'm guessing _get, _set, and _call have to do with at least one of them.)

Delegation is a mechanism in the Objective-C Toolkit AppKit as it was sold with NeXTstep. It allows you to set a delegate object for any object. Method calls that cannot be handled by an object with a delegate have a chance to be handled by the delegate instead of the original object before a runtime error is being generated.

It was standing coding practice in NeXTstep to have a subclass of Application as your application, and implement many methods in application that would otherwise require subclassing of Window, Menu or other widget classes. Instead one used stock GUI classes and just set up the application instance as a delegate.

While that violated normalization principles preached by the C++ crowd, it also made many things easier, especially for little "I need to hack up a little GUI tool" projects.

In emulation, an object acts as a proxy for another object. Using introspection and the same mechanism as delegation you could code generic proxies that acted as whatever object you ordered them to stand in for. That allowed the creation of generic RPC proxy objects, which you called locally, but contained only the scaffolding and marshalling code needed to locate a matching implementation and to ship the call parameters and results.

Posing is a special case of emulation, where you subclass and upgrade a class, and then tell the subclass to replace the superclass, ideally system wide. There where subclasses of the NeXTstep image class that added some two dozen image file formats to Image, which patched themselves backwards into the system as drop-in replacements for Image. Any application that used Image instances or subclasses Image inherited the improved Image's capabilities and added formats.

But I do think if you're going to add support for a programming paradigm to your language, you should not design it in such a way that it's incredibly unintuitive and dangerous (thinking specifically of pass-by-copy here).

Have worked with PHP since the times of PHP/FI, I can tell you that this is not the PHP approach. PHP is the borg of programming languages. It just adds the technology of other languages to PHP and sees what comes out of it. The PHP release and development cycle will then adapt that.

PHP is not regular, and not beautiful. It is also not consistent.

As a programming language, PHP emodies the ideal of incremental improvement in as many way as possible:

PHP adds features in an incremental way.

It allows first time users to enter the realm of programming and takes them from "echo $PHP_SELF" to Templates, SQL and OOP in incremental steps that are no larger than can be learned in a single afternoon each.

And it adds new features and functions, or refines existing features and functions with each minor release.

Also, PHP took this paradigm and applied it to the PHP documentation, which is a funny cross of prinable book and WikiWiki - user input to the docs is slowly and incrementally being integrated into the main docs body.

So if Java is a consultant from IBM with suit and tie, and Python is an academic from the cs languages dept a european university, PHP is wearing an overall with oil stains on it and it has dirt in the face, but it somehow gets the job done.

Re:history of PHP OO?

[the quick brown fox]

So if Java is a consultant from IBM with suit and tie, and Python is an academic from the cs languages dept a european university, PHP is wearing an overall with oil stains on it and it has dirt in the face, but it somehow gets the job done.

That is exactly what I always suspected was the case with PHP, but I've never been able to get a serious PHP programmer to confirm it. Thanks.

A little off the subject, but, I don't think Python is an academic kind of language at all; if anything I feel like it's a less web-centric, better-designed PHP, or more readable, better-designed Perl. Same for Ruby, although Ruby does take a step toward CS-land by taking a lot of (good) lessons from Lisp.

Re:history of PHP OO?

[tiptone]

you said:
"They would have been better off delaying the final release of PHP5 a year or two and just going through and converting the entire library to an OO model. That would be a step in the right direction."

i think that would have made it Java or C#, both of which are really nice languages, but a scripting language shouldn't _have_ to be OO, just have the ability to do it if you want. i like the way it stands now, OO if you want it, or just straight-forward procedural scripting if you want it like that.

i much prefer being able to do:
echo "testing line";
as opposed to _having_ to type:
System.Console.WriteLine("testing line");

i think the all-or-none approach to OO belongs in another language.

Re:history of PHP OO?

[wtd]

That's Java/C# OO. Ever used Ruby? :-)

I'm thinking of things like:

$arr = array();
array_push($arr, 42);

vs.

$arr = new array();
$arr->push(42);

To me that removes a lot of redundancy, plus, making core functionality reusable via standard OO mechanisms would be a significant improvement.

Of course, proper namespaces/packages would help as well. The previous example might look more like:

$arr = array::new();
array::push($arr, 42);

Though there's still redundancy here, in that I know $arr is an array, and I shouldn't have to restate that everytime I do something to it, at least it becomes easier to remember what function and procedure names are because they're shorter, and all grouped in an "array" package.

Re:history of PHP OO?

[tiptone]

only written a little bit of Ruby (nice language BTW), nobody ever offered me a job writing it :)

i understand where you are coming from in your example, but still disagree that that's the way it should have been done. allow me to expand on your example.

$arr = array();
array_push($arr, 42);

can also be done like this as long as _everything_ isn't an object.

$arr[] = 42;

which couldn't be done if it was all switched to OO, which is why i prefer having OO avaialable instead of necessary. now i can still use the built-in functions like array_push() and array_pop() without _having_ to make an object to use them.

i like the syntax of your second example and could deal with writing code like that (still prefer to have it be an option in PHP). i hate that last example you gave and would have to be paid highly before i would use a language with such syntax. but i would do it for the right money :)

Re:history of PHP OO?

[the quick brown fox]

$arr[] = 42;

There's nothing really non-OO about this, as long as the syntactic sugar of [] can be translated into a method/attribute call.

Re:history of PHP OO?

[wtd]

All you would need is the ability to overload operators, and the ability to assign to an expression which returns a reference.

Againb, with Ruby on the brain, the simpler syntactic sugar would be:

$arr << 42;

Re:"Java programmers will be pleased"

[the quick brown fox]

What's wrong with a standard toolkit of 1500 separate classes?

Desperately seeking spellchecker

[flockofseagulls]

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.

Pleased? Why?

[Phouk]

Java programmers will be pleased.

Personally, I'm less than impressed. Why should I cheer and hooray about PHP introducing some OO features in PHP in 2004 almost all of which Java has had since version 1.0 in 1995? Is that supposed to be a great feat?!

Re:Pleased? Why?

[AuMatar]

Java was designed to be an OO language. PHP was not.

Personally, I'm not impressed for other reasons. OO is severely overrated- its a good solution for some problems, its a bad one for others. It is not the holy grail, and its not meant for use on every project. I don't see it as being truely useful for a web scripting language.

Re:"Java programmers will be pleased"

[AuMatar]

Several things.

1)Its too big. With 1500 classes there's no way a developer can keep a significant chunk in his mind

2)Its too big part 2- the bigger the library, the more bugs it has

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. Huge projects like Java's framework end up producing subpar code

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

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

Does OOP make sense for web scripting?

[flockofseagulls]

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.

OOP clearly makes sense in many applications where the class definitions and objects have a lifetime longer than a single call. And it's possible to write server-side applications that "live" longer than a single HTTP request. But that isn't the PHP execution model.

The ZEND Accelerator has clever caching and compilation mechanisms, but how many people have the Accelerator installed? How many ISPs? Without those optimizations the PHP interpreter is scanning/compiling the entire script (including all of class definitions) for each request. In that environment it makes sense to keep the scripts as short and simple as possible, not add code and complexity with OOP.

I'm not saying that OOP is a bad idea, even in PHP code. But does it make sense to implement full-blown OOP instead of using included files for common code? In my PHP 4 projects I mainly used classes to get a namespace, not for any other OOP purposes.

Re:Does OOP make sense for web scripting?

[Anonymous Coward]

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:

require_once 'Customer.php';
$c = Customer::findID($_GET['id']);
$c->first_name = 'Joe';
$c->save();

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.

Re:Does OOP make sense for web scripting?

[flockofseagulls]

Thanks for the thoughtful reply. My question was "Does OOP make sense for web scripting." You answered a different question, something like "Explain what OOP is for."

I don't have any problem understanding OOP, thank you -- I've been programming for a long time and learned OOP in Smalltalk and C++ back when they were new.

I'm not asking whether OOP is a worthwhile technique or not. I'm asking if it makes sense, in general, for web applications, where class definitions and object instantiations and initializations are done to handle a single HTTP request.

I don't have benchmarks, but it stands to reason that defining a class, initializing objects from a persistent store, then using those objects will frequently involve more code than a non-OOP approach. Not always, but I could give some examples if the principle isn't apparent. In an interpreted language like PHP, performance is usually directly correlated to code size (again, not always). The ZEND compiler and caching mechanisms may make this a non-problem, as would using the commercial ZEND products or one of the add-on PHP caches, but in my PHP experience (4 years now) I've never known any client site to use those, and none of the ISPs I've worked with have those features installed.

Simplifying code, improving module cohesion and reducing coupling, making code easier to understand -- all of the selling points of OOP -- may offset the (possible) performance penalties. I've coded PHP both ways, I'm not persuaded that OOP makes a lot of sense given the straightforward and transient nature of many (not all) web applications. So with PHP 5 emphasizing OOP much more than PHP 4, I ask, does OOP make sense for web scripting?

If you have insightful comments or experience, great, but I don't need programming lessons or irrelevant defenses of OOP.

Re:Does OOP make sense for web scripting?

[flockofseagulls]

Thanks for answering your own questions.

I did not question OOP in PHP only for performance reasons. And I know that the web applications can maintain state on the server, including PHP applications.

If it is, then I would say that performance is the foremost non-issue of modern software development, and following Moore's law, it becomes 50% less relevant to your development approach every 18 months.

Moore's Law (a conjecture that has more or less held so far) refers to hardware; in fact it refers to the density of transistors on integrated circuits, not to performance. It does not necessarily follow that software automatically gets faster as transistor density increases. Anyone who used computers ten or twenty years ago knows that modern applications are not thousands of times faster than they were back then, even though the hardware is.

Application performance is not a non-issue. Concern for code size and performance, as it relates to programming techniques, is not the same thing as premature or micro-optimization, which is generally a bad way to write code.

Your command of buzzwords is impressive, but you didn't address my original question.

Re:Does OOP make sense for web scripting?

[kris]

That's a lot of scaffolding to build and tear down for every HTTP request.

It is, and overdone OO framework is what makes PHP web applications slow. The faster PHP applications only use a limited amount of OO, and like you did, as a namespace management tool.

But PHP 5 is a base for more than mere web applications. The version 5 update readies PHP to leave the web application scope and makes it a fully blown scripting language. PHP is already being used in this context, albeit not yet fully recognized - most people still associate PHP with the web, like you did.

In the context of regular scripting, the capabilities of version 5 do make sense. They are in fact an enabler that allows proper management of larger and more complicated applications than what you see on the web.

In terms of OO-ness, PHP is more like Objective-C than it is like C++ - it is a dynamically typed language that allows for complete self-description of classes. This calls for a coding style that is more like Objective-C than C++, too - expect PHP frameworks to have larger classes and less deep class hierarchies than you are used in the C++ or Java worlds. Expect to see the use of delegation, and of the signal-slot paradigm.

Re:Does OOP make sense for web scripting?

[flockofseagulls]

Let me add an example of what I'm getting at. Is this:

$db = mysql_connect('server', 'user', 'password');
mysql_select_db('foo', $db);
$rs = mysql_query('SELECT name,age FROM people');

while ($row = mysql_fetch_assoc($rs)) {
echo $row['name'] . ' : ';
echo $row['age'] . '<br>';
}

Somehow worse or less preferable than this:

require_once 'DB.php';
...
$db =& DB::connect('mysql://user:pw@host/foo');
$db->set FetchMode(DB_FETCHMODE_ASSOC);
$rs =& $db->query('SELECT name,age FROM people');

while ($row =& $rs->fetchRow()) {
echo $row['name'] . ' : ';
echo $row['age'] . '<br>';
}

The second example drags in a the whole Pear::DB class and all of its baggage, to do the exact same thing as the first example. I know that Pear::DB supports multiple database back-ends and has other conveniences, but if I don't use them, and my database back-end is unlikely to change (as is usually the case), is Pear::DB worth the extra code?

Taking the idea a step further, what about programmers who wrap Pear::DB inside more layers of abstraction:

class people
{
var $db; // database connection
var $name;
var $age;

function people() { ... }

function get_person($id) { ... }
function save_person($id) { ... }
}

...

$person = new people();

foreach ($person_id in $list_of_ids) {
$person->get_person($person_id);
echo $person->name . ' :' . $person->age . '<br>';
}

I've seen fairly elaborate class structures that essentially do what could be accomplished in a few lines of PHP. As for reuse, putting the common bits of code in an include file accomplishes the same thing as the classes. As I mentioned in my first post, the main benefit of classes in this situation is to get namespaces, so re-using included code is less likely to cause conflicts.

I understand that in some applications OOP techniques simplify code and encourage re-use. But in other applications OOP techniques add a lot of extra code and overhead with no actual benefit. Just doing everything with classes and objects without getting a real benefit (not just ideological satisfaction) doesn't make any sense.

If the class hierarchy (whether Pear or something else) includes hundreds or thousands of lines of interdependent code, it's hard to argue that OOP is simpliying or adding to maintainability, even if we ignore the performance issues.

I have written PHP applications that benefited from OOP techniques, but the majority of the PHP work I've done was (or would have been) simpler and faster without trying to force an OOP style on it.

Re:Does OOP make sense for web scripting?

[flockofseagulls]

But PHP 5 is a base for more than mere web applications. The version 5 update readies PHP to leave the web application scope and makes it a fully blown scripting language. PHP is already being used in this context, albeit not yet fully recognized - most people still associate PHP with the web, like you did.

I know that PHP 5 is being positioned as more than a web language. I doubt it will succeed there. That space is well-served by more mature and better thought-out dynamic languages such as Perl and Python, and compiled languages such as Java and C++.

I have nothing against PHP as a general-purpose language, but I'll be a little surprised if it makes serious inroads outside of the web application domain. Maybe PHP 5 will tip the balance.

I worked on several large web projects that had non-web scripts to do various maintenance tasks (like indexing, workflow, publishing). We started to use PHP 4 for those things, thinking it would be easier to have everything in a single language. But PHP 4 proved frustrating as a general-purpose scripting language, and hard to debug. We eventually used Python and Perl for the non-web code.

Re:Does OOP make sense for web scripting?

[kris]

I know that PHP 5 is being positioned as more than a web language. I doubt it will succeed there.

For many people, earlier versions of PHP have been their first programming language. Wait to see them grow up - PHP grows with them.

Re:Does OOP make sense for web scripting?

[tiptone]

you said:
"I'm asking if it makes sense, in general, for web applications, where class definitions and object instantiations and initializations are done to handle a single HTTP request."

yes or no depending on how you look at it :)

lots of times it doesn't boil down to a single HTTP request. there are lots of web applications that span multiple pages (HTTP requests) and use the $_SESSION for persistence.

i don't think that PHP 5 is really emphasizing OO as much as making sure it's apparent to everyone. after all, it is the "big new thing" for this release. try and imagine huge complex "web applications" instead of one or two page form submissions scripts and OO becomes as useful as it is in any other language.

if you don't like OO you just don't like it (not saying you don't) but the fact that PHP is used mainly as a web language should have no impact on rather or not OO is used (correctly).

Re:Does OOP make sense for web scripting?

[flockofseagulls]

For many people, earlier versions of PHP have been their first programming language.

I don't know which crowd of young programmers I'm more worried about -- those who learned PHP as their first language, or those who learned Java. I've mopped up enough amateur PHP (and ASP/VBScript) projects in the last few years. It's a flashback to the days when people learned some simple home computer BASIC and then got a job in corporate IT. Not necessarily bad, but you sure can learn a lot of bad habits, and fail to learn some good ones, if you start with the wrong language.

I think Python is a much better first language, but I have to admit it doesn't have the traction PHP has -- I use PHP for almost all of the web projects I do. But I also know enough about programming to know what parts of PHP to avoid, when OOP is overkill and when it helps, etc.

Re:Does OOP make sense for web scripting?

[rjshields]

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.

Java and C# are both object oriented languages and have hugely successful related web development platforms (J2EE and .NET), so what was that point again? :)

Re:"Java programmers will be pleased"

[Anonymous Coward]

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.

static typing

[primus_sucks]

Java programmers will be pleased.

I'll be pleased when PHP gets static typing.

Re:static typing

[flockofseagulls]

I'll be pleased when PHP gets static typing.

Why? If you want that just use Java.

Adding more and more Java-like features to PHP is going down the wrong path. Web programmers took to PHP enthusiastically because the language is simple, the libraries are extensive (if not always robust), and you can get something working fairly fast.

If PHP continues to bloat with OOP and exceptions and perhaps static typing, it will lose its advantage and appeal. If PHP morphs into a kind of patchwork Java -- with all of the requirements and hassles but none of the grace -- programmers will just use Java.

I don't think Java is a particularly graceful or friendly language, but PHP is even less graceful (though more friendly).

I'm seeing the same thing happen in the Microsoft world, as ASP programmers get pushed into .NET. ASP/VBScript is less powerful (and less graceful) than PHP, but it is much easier to get easy things to work in old-style ASP than in .NET. Fortunately for Microsoft .NET is well-designed enough to keep most of their platform developers from looking too fondly at Java.

Re:"Java programmers will be pleased"

[ttfkam]

1. Classes are encapsulations of logic (variables and functions). What was once a shared library on its own can be distilled to one or a few classes. If each class had about five methods (functions) and two static properties (variables), the equivalent code body would be 7,500 functions and 3,000 global variables. Since classes/objects (and packages!) keep similar functionality compartmentalized, it's actually easier to keep a significant chunk in mind. Interfaces (method definitions without implementation) make it even easier. Personally I haven't had a problem keeping the packages I use on a project straight in my mind. But then, maybe I'm just smarter than you.

2. The smaller the library, the less it does. What's your point? At the end of the day, when your project (without objects or a complete standard library) is finally ready, you have linked to quite a few shared libraries, reinvented the wheel twice, and have very little standardized that would be recognized by the next person who comes to maintain the project.

The more the standard library does, the less code (with bugs) you have to write and maintain. The great part about the standard library is that since everyone is using it, everyone's finding and fixing the bugs together. That said, the Java standard library has been extremely solid for me. What bugs have you run into habitually? You do have some examples right?

There is no requirement that a developer use all features of a standard library any more than it's required that a developer use every interface defined by POSIX in every project. But in both cases, it's nice to know the standard interface for your next project is there.

3. Yes, better to compartmentalize items. Make separate components. Put them in... ummm... PACKAGES. Yeah, that's it. That way I can keep my general utilities and basic data structures separate from my I/O routines which are kept away from my database layer and my GUI and... java.util, java.io, java.sql, java.awt, etc. So what's the problem?

Huge projects like C's standard library and the hodgepodge of 3rd party libraries end up producing subpar code. Your point?

4. Yes! Because Java hasn't changed in the last ten years at all. Pray tell, what innovations were you speaking of? The innovation of yet another person making yet another linked list or hashtable tailored exactly for their needs? (Wee! This keeps a specific type of object in 1KB less per thousand objects than the standard! I am 7331!) You want to talk about innovation? C and C++ coders couldn't get together to decent database abstraction layer. ODBC (although more specifically the drivers written for that vague standard) is such a piece of crap, people started actually thinking datasource abstraction was a bad idea. What about the fact that few C or C++ (or LISP or Perl...) coders bothered to make documentation at all let alone generate it from the source code itself until javadoc came along. Now it's all "we have that too!"

If you're spending all your time reinventing the wheel, when do you have time to make something new? ...to innovate? Innovation comes when you don't have to reinvent the wheel and can concentrate on the task at hand (which probably isn't determining the next new hashtable implementation).

5. Nothing says innovation quite like "Fuck! The library changed interfaces again. Alright, let's go back, fix stuff, and rebuild again." In Java, you can remove/change things as well. It's this thing called "deprecation." Perhaps you've heard of it. It's present in other languages as well. You tell people that something is changing/going away and then later on you change it or make it go away.

But then, more often than not, keeping the old code around doesn't hurt anything, it just doesn't change. So tell me, how many versions of the standard C library do you have around? And that's just one library! By comparison, the definitions for String and StringBuffer, two fundamental cl

"You're not Ali. You're not even...literate."

[mcasaday]

A much more better speled deskripshun of PHP5's OO language enhancements are is available from the horse's mouth

Re:"Java programmers will be pleased"

[AuMatar]

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?

Because the developer doeesn't have to learn 200 libraries, he'd only need to learn the subset he frequently uses. The java class library is very highly coupled. To use the networking part, you need to understand all the data structures part.

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?

Bug occurance isn't linear with LOC, its exponential. The fact that with separate smaller libraries people would be focusing in on smaller chunks of code means each chunk would have fewer bugs. Bug occurance vs LOC relationships has a lot of research on it, they all say that small independantly written chunks get fewer bugs/LOC than large masses of code.

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?

Can you keep track of every component of a million LOC project? I know I can't. As size goes up, complexity goes up, and bugs go up. This is basic software engineering, the research on this has all come to this conclusion since the 70s.

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.

No you aren't. If you're designing something, you use the functionality you need to get the features written. Using advanced functionality just for the sake of using it is a bad idea. Rule of thumb- if you use something because it seems like a clever trick, its going to be hard to debug, hard to maintain, and is more likely to have bugs than if you had done it the simple, "less advanced" way.

As for your swing exaple- horrid example as swing doesn't come close to working the same on Windows and Unix. ANd it doesn't address the point I made at all.


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!

Instead you have cruft building up in the giant standard library, and people using that cruft in new applications, making it even more important to keep it. In the meantime, it becomes increasingly difficult to write Java implementatiions because the cruft needs to be carried forward, and youu lose the only benefit of the large class libraries- similarity of style- because the cruft can't be kept up to date without breaking compatibility

Huge standard libraries come with few, marginal at best pluses. In fact, the only one that comes to mind is writing all the classes in a similar style. The problem there is that the same style doesn't fit all types of classes, which is why Java's library is so poor.

Re:"Java programmers will be pleased"

[AuMatar]

1. Classes are encapsulations of logic (variables and functions). What was once a shared library on its own can be distilled to one or a few classes. If each class had about five methods (functions) and two static properties (variables), the equivalent code body would be 7,500 functions and 3,000 global variables. Since classes/objects (and packages!) keep similar functionality compartmentalized, it's actually easier to keep a significant chunk in mind. Interfaces (method definitions without implementation) make it even easier.

And separate libraries keep it even more compartmentalized. My networking library requires no knowledge of my hash table or linked list. With one library like Java's, to know one part you need to know a large chunk of it. Part of it is the ridiculous depth of the hierarchy they use, part of it is due to the high degree of cross-linkng between sections. Its not a well designed library.

2. The smaller the library, the less it does. What's your point? At the end of the day, when your project (without objects or a complete standard library) is finally ready, you have linked to quite a few shared libraries, reinvented the wheel twice, and have very little standardized that would be recognized by the next person who comes to maintain the project.

THe point is that projects don't need the 1500 classes. THey'd be better off downloading libraries that just do what they need. Chances are those libraries will do a better job than the one size fits all standard library.

As for reinventing the wheel and no standardization- no, you search the web, find libraries, or go to a library repository to find one. No reinventing needed, and I've never had a problem to have standardization. Of course, maybe I'm just a better programmmer than you.

The more the standard library does, the less code (with bugs) you have to write and maintain.

No, when you write in a language without one you use libraries others have written still, either open source or for purchace.

3. Yes, better to compartmentalize items. Make separate components. Put them in... ummm... PACKAGES. Yeah, that's it. That way I can keep my general utilities and basic data structures separate from my I/O routines which are kept away from my database layer and my GUI and... java.util, java.io, java.sql, java.awt, etc. So what's the problem?

Because it doesn't work like that. Due to the standard library's attempt to keep consistent styles and interfaces, you get functionality thats shoved into implementations that don't work well. Meanwhile separate libraries get to pick the model that fits them best.

Huge projects like C's standard library and the hodgepodge of 3rd party libraries end up producing subpar code. Your point?

Umm, C's standard library has fewer functions than Java's does classes, its hardly huge. And using different libraries produce SUPERIOR code, bcause you pick the ibrary that best suits your code, not the one that came in the standard library because its there.

The best comparison is- Java's library is McDonalds. Its edible, you can get by on it, but it isn't very good.

Yes! Because Java hasn't changed in the last ten years at all. Pray tell, what innovations were you speaking of? The innovation of yet another person making yet another linked list or hashtable tailored exactly for their needs?

Wow, you're oblivious. There's been improvements on even simple sstuff like strings that has improved average performance in the past 5 years. COW is one that's come into use. Similar techniques have popped up in hash tables and lists. FOr large tables and lists, a library using modern techniques is at least 10% better than it was 5 years ago.

What about the fact that few C or C++ (or LISP or Perl...) coders bothered to make documentation at all let alone generate it from the source code itself until javadoc came along. Now it's all "we have that too!"

A

Java Devs will be Pleased

[mattwarden]

Yes, Java developers will be pleased... because they'll stick with Java. PHP is destroying its niche by trying to go the Java-ish OO route.

Re:"Java programmers will be pleased"

[the quick brown fox]

It sounds like you are objecting to three separate things.

A) Sun implemented too much functionality. (1, 2)

B) All of that functionality is built into one library instead of separate downloadable libraries. (3)

C) Every JVM is required to come with the library. (4, 5)

I respectfully but wholeheartedly disagree with you on all points.

A/1,2) I applaud Sun for raising the bar in delivering so much functionality. For the most part, the packages are well organized enough that the classes you don't use don't bother you. (For example, there have to be hundreds of classes in java.awt.*, but if you only write webapps or CLI apps, you don't even have to know they exist.) As for bugs, I haven't found the Java libraries to be more buggy than the vast majority of third-party libraries I've used. In fact, they are far less buggy because there are so many eyes on them (i.e. all the millions of Java developers out there).

B/3) Granted, not all of the packages are absolutely best of breed. (AWT/Swing come immediately to mind.) But most of them are quite well written, by fine minds like Josh Bloch and Doug Lea. I don't think there are many people in the world who could have written this. Overall I think the quality of code in most of the Java platform classes is at a level that almost any development organization would be proud of. And anyway, I don't see how code quality is related to a deployment decision like "should this be one JAR or seventeen?". What you're really saying is all this code shouldn't have been written by Sun, because you assume they don't have enough developers or that those developers are not focused enough on their tasks. (Right??)

C/4,5) The Java community has not proven to be short on innovation. There have in the past been plenty of third-party Java collection classes (Trove, Commons Collections, Commons Primitives, tclib, FastUtil, PCJ, Mango). I would like to see some more specific examples to back up your claim of "huge losses in productivity". (Although the general argument may not be totally without merit, because the .NET development community does in general seem to shun non-Microsoft libraries and technologies.)

As for your backward compatibility argument, I don't see how a widely used library should have any less of a responsibility to remain backward compatible with previous versions, than a language does.

And from just a common sense perspective, can you seriously mean that a modern language shouldn't have built-in types for such basic abstractions as string, list, hashtable? Do you really think this kind of crap is an improvement?

Point by point

[ttfkam]

And separate libraries keep it even more compartmentalized. My networking library requires no knowledge of my hash table or linked list. With one library like Java's, to know one part you need to know a large chunk of it. Part of it is the ridiculous depth of the hierarchy they use, part of it is due to the high degree of cross-linkng between sections.

So you're saying that if a networking library requires a linked list or hashtable it should roll its own rather than reusing an existing, efficient implementation?

Also, your example seems contrived. Please show me where I need to access a linked list from within the classes in java.net. Will some List implementation be loaded by the classloader in your networking program? Probably, but not by the networking packages. If it's loaded, it's because the programmer needed a List.

Also, a JVM will likely have quite a few *.so files lurking in the background. Unless the classes that need the native support are loaded by the classloader, the loadlibrary call is never called for them. Class definitions aren't loaded into memory unless they're used.

THe point is that projects don't need the 1500 classes. THey'd be better off downloading libraries that just do what they need. Chances are those libraries will do a better job than the one size fits all standard library.

You'd advocate splitting off the string handling functions of the standard C library from the other functions? Sure, it's a different header file, but it's the same *.so file. After all, all I need to do in my program is tokenize a string and spit it back to the console. Why should I have to map a 1.2MB library just for that? (By the way, I was being facetious.)

As for reinventing the wheel and no standardization- no, you search the web, find libraries, or go to a library repository to find one. No reinventing needed, and I've never had a problem to have standardization. Of course, maybe I'm just a better programmmer than you.

Or maybe you enjoy dealing with twenty different ways of threading. And if you point to your one favorite threading library, do you use that same library on UNIX, Mac, et al.? Or are you the type that states that threading has no place in software -- a fork is the only true way kinda guy. What about database access? ODBC or do you code each and every database separately? (Then again, with ODBC, you have to make enough special cases that indeed you do code each and every database somewhat differently.)

My point is these are solved problems. And for that matter, there is nothing stopping a person from writing their own linked list or hashtable implementation. Nothing. Why doesn't anyone? Because over and over what has been seen is that the standard ones are either (a) better or (b) good enough that the extra effort isn't worth it. I know that (b) probably upsets you, but if my project isn't about hashtables and the difference between the two implementations would have a negligible impact on the overall project, it's not worth doing. Reinventing the wheel in this case is what KILLS innovation.

The best comparison is- Java's library is McDonalds. Its edible, you can get by on it, but it isn't very good.

Enough hyperbole. Please show me where the JSL is deficient. Let's debate specifics.

There's been improvements on even simple stuff like strings that has improved average performance in the past 5 years. COW is one that's come into use. Similar techniques have popped up in hash tables and lists. FOr large tables and lists, a library using modern techniques is at least 10% better than it was 5 years ago.

It's funny you should mention that. I'm assuming you are talking about C++'s std::string and using type traits and template parameters to make appropriate forms of strings for the task at hand. (See, I read Modern C++ Design and Dr. Dobbs too.) First,

Re:"Java programmers will be pleased"

[rjshields]

Your argument seems to revolve around the fact that the J2SE library is too big and poorly designed. Do you actually have proof to back this up, or is just heresay?

You also make the point that it is good to be able to pick and choose which library to use, slating Java because it does not allow this. Since when did Java not allow you to use whatever library you want? If you want to write your own HashMap, LinkedList or implementation of the networking libraries, or use someone else's, go right ahead. Whether or not it is a good idea to continually reinvent the wheel is another matter. Standardisation and standard libraries bring with them many benefits.

J2EE consists of a bunch of specs and reference implementations, encouraging different implementations of a single specification to be developed for different needs.

I'll continue to not use them and end up with easier to write and better performing applications than yours.

That's fine, but don't forget that PHP is merely a web scripting language.