Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Going Dynamic with PHP

ScuttleMonkey posted more than 7 years ago | from the not-the-bastard-child-of-languages-anymore dept.

222

Five-Oh writes to tell us that IBM DeveloperWorks has an interesting article about the OO advantages of PHP V's new features. From the article: "PHP V5's new object-oriented programming features have raised the level of functionality in this popular language significantly. Learn how to use the dynamic features of PHP V5 to create objects that bend to fit your needs."

cancel ×

222 comments

Sorry! There are no comments related to the filter you selected.

PHP's Comeupance (5, Informative)

(1+-sqrt(5))*(2**-1) (868173) | more than 7 years ago | (#14762257)

I rediscovered PHP last week after a year-long hiatus, and was surpised to find that it approacheth Java in reflection and information hiding; that said, there are some lamentable lacunæ:
  • Class constants must be string literals and only string literals (no variables, arrays or objects).
  • Type-hinting is confined to arrays and objects (feature?).
The unadorned output of phpDocumentor, PHP's analog to JavaDoc, is also suboptimal; for documenting PHP, therefore, go Doxygen [doxygen.org] .

Re:PHP's Comeupance (-1, Troll)

Anonymous Coward | more than 7 years ago | (#14762423)

>> there are some lamentable lacunæ

"lacunæ" - WOW! Ligatures and all!

>> is also suboptimal

'Suboptimal'?

I think your life skills and ability to interact with people "in the 'meat zone'" must be somewhat 'suboptimal' too.

Do the dreaded 'normals' laugh and point at you in the street?

If you were my kid I'd take you behind the barn and shoot you.

Re:PHP's Comeupance (1, Flamebait)

(1+-sqrt(5))*(2**-1) (868173) | more than 7 years ago | (#14762451)

I think your life skills and ability to interact with people "in the 'meat zone'" must be somewhat 'suboptimal' too.
Actually, being a modern incarnate Franz Liszt, I've had more vagina than you can shake a stick at.
If you were my kid I'd take you behind the barn and shoot you.
You'd have to contend with my .357 magnum, however.

Re:PHP's Comeupance (-1, Redundant)

Anonymous Coward | more than 7 years ago | (#14762668)

"...being a modern incarnate Franz Liszt, I've had more vagina than you can shake a stick at."

Delusions of grandeur, pompous egocentrism, and irrefutable evidence of bad taste. You win, all right.

Re:PHP's Comeupance (0)

Anonymous Coward | more than 7 years ago | (#14762931)

Wings and toxic suit deployed. I am now immune to the rising tide of bullshit in this thread.

Posters, please take a hit from your inhalers and step away from the keyboard for 20 minutes. Other people might not have their wings yet and drown.

-AC

Re:PHP's Comeupance (0)

Anonymous Coward | more than 7 years ago | (#14763058)

Actually, being a modern incarnate Franz Liszt, I've had more vagina than you can shake a stick at.

I dunno...I've shaken my "stick" at a lot...

Re:PHP's Comeupance (5, Funny)

Hal_Porter (817932) | more than 7 years ago | (#14762885)

Dear (1+-sqrt(5))*(2**-1),

I must say, Sir, that I salute you for your post. Not only is in Informative, it is also well drafted in the Queens English, not in the debased language of Internetland. Furthermore, you have managed to obtain the coveted pole position of posters, so to speak. As I write this epistle of congratulations, I shall drink a toast of finest port wine to you, and I wish that your correspondence with the world shall continue for all eternity.

If I may be so bold as to trouble you with two requests, it would be these. Firstly, may I post a copy of your memorandum above the post to which I fasten my servants when I whip them for dumb insolence and/or sundry grammatical errors, including the splitting of infinitives or the use of the accursed Internet language? Secondly, my wife is expecting our first child, conceived soon after she spent a night in my servants quarters, teaching them virtue of prayer. Would it be presumptive of me to command her to name her baby (1+-sqrt(5))*(2**-1). We are unsure at present of the sex of the baby, since we have emigrated to the 19th Century to escape the linguistic slovenliness of the later epochs, but we feel that such a name would distinguish a child of either gender?

Yours, etc
Hal Porter, esq.

PHP 4 V. 5 (1)

wesw02 (846056) | more than 7 years ago | (#14762277)

I'm curious about the Differences between PHP 4 and PHP 5, can someone provide a link, or first hand info about the good and bad of PHP 5.

Re:PHP 4 V. 5 (1)

karvind (833059) | more than 7 years ago | (#14762325)

Google is your best friend.

From php.net [php.net]

Re:PHP 4 V. 5 (3, Informative)

drpimp (900837) | more than 7 years ago | (#14762348)

This page actually has alot of links of changes and new features. What's New [faqts.com]

Re:PHP 4 V. 5 (5, Informative)

lbft (950835) | more than 7 years ago | (#14762374)

There's a good summary on Zend: http://www.zend.com/php5/andi-book-excerpt.php [zend.com]

Basically, PHP 5 adds proper object support (think Java-style) including iterators for objects, and new extensions add good XML support, SOAP, SQLite, better MySQL support (prepared statements, OO interface, etc.)

I'd recommend reading Adam Trachtenberg's book Upgrading to PHP 5 [oreilly.com] if you're familiar with PHP 4.

Re:PHP 4 V. 5 (0, Troll)

Heembo (916647) | more than 7 years ago | (#14762875)

...but PHP does not force object orientation - you can still write all the sloppy RAD procedural non-variable-verifying web-code you want with PHP! Sure, you can still write sloppy Java code, but PHP does NOT have the enterprise integration, security or advanced language features of Java or *gasp* C#.

Re:PHP 4 V. 5 (2, Insightful)

Parham (892904) | more than 7 years ago | (#14762988)

Your comment is true, but the same can be said about Perl (it just sounded like you were putting down PHP only).

Re:PHP 4 V. 5 (2, Insightful)

jZnat (793348) | more than 7 years ago | (#14763092)

This is what frameworks are for. Security and performance conscious people like myself write them so that other neophytes and developers alike can make good PHP apps without worrying about those things.

Re:PHP 4 V. 5 (0)

Anonymous Coward | more than 7 years ago | (#14763149)

I wouldn't characterize the object support as "proper", as it is missing some key features, like multiple inheritance and namespaces.

Re:PHP 4 V. 5 (4, Informative)

Foofoobar (318279) | more than 7 years ago | (#14762447)

PHP5's object are passed via reference by default. Public/Private function and variables in classes are also now supported. The language as a whole has better OOP support and the underlying engine is alot faster as well.

Also, some deprecated functionallity has finally been dropped. All in all, I've been using PHP5 for awhile now and everything works alot faster as a whole (as I use it with Apache 2 as well).

One note that might concern you, PHP5 does not come with MySQL built in anymore. You either have to download the update or compile it yourself. It's nice for those who want to use something aside from MySQL and don't want to have to keep it the module loaded constantly but it's also a pain for the beginner hobbyist who has never had to deal with installing the MySQL module for PHP.

Re:PHP 4 V. 5 (2, Informative)

Anonymous Coward | more than 7 years ago | (#14762710)

For the beginner/hobbyist I found LAMPP, more specifically XAMPP, to be very easy to use. The newest version came with PHP5 and mysql 4.1 (i think). It installs in minutes and works on linux and windows.

Re:PHP 4 V. 5 (2, Interesting)

jZnat (793348) | more than 7 years ago | (#14763107)

PHP5 uses MySQLi [php.net] which has both a procedural and object-oriented interface, and it supports features from MySQL 4 and 5 such as transactions and stored procedures. The old MySQL libraries are technically for MySQL 3, so there's not much need for those anymore.

Then there are PHP Data Objects [php.net] for a unified database interface (although it is a bit primitive when compared to PEAR DB [php.net] and other DBIs).

Please Note: (0)

Anonymous Coward | more than 7 years ago | (#14762308)

Programmers are responsible for implementing bend() or acquiring alcohol-fueled robots before folding objects.

Bend Over: +1, Helpful (-1, Troll)

Anonymous Coward | more than 7 years ago | (#14762313)


For Al-Qaeda [whitehouse.org] .

Welcome to the United Gulags of America.

Patriotically as always,
Kilgore Trout, C.E.0.

A bit off topic... (-1, Offtopic)

cosmotron (900510) | more than 7 years ago | (#14762314)

But how come the New York PHP Conference logo [php.net] looks just the like CDPHP [cdphp.com] 's logo?

Re:A bit off topic... (1)

B3ryllium (571199) | more than 7 years ago | (#14762393)

If you think those look similar, I can't begin to imagine your opinion of every company's logo for the last six years.

Re:A bit off topic... (0)

Anonymous Coward | more than 7 years ago | (#14762761)

That CD PHP Logo looks a lot like the Nike Swash to me.

If you're going to be this generic... (2, Insightful)

xxxJonBoyxxx (565205) | more than 7 years ago | (#14762329)

If you're going to be this generic, why lock each class to a single table? (Why not let the name of the table be an argument as well?)

The answer would seem to be that there is no input validation or output interpretation going on in this sample. So, you can either write a switch block that makes sure your integers are in valid ranges, etc. or go back to individual properties. (Six dozen of one, half of the other.)

Re:If you're going to be this generic... (1)

cnerd2025 (903423) | more than 7 years ago | (#14762504)

Amen. My issue with databases and all that is that they are not abstract enough. Either one must create a new table when one wishes to implement a new feature, or one must develop some extremely generic database that is hard to search. I don't think that moving toward Java is necessarily the answer.

This will be off-topic

(Six dozen of one, half of the other.)

Hahaha. That was priceless. I assume you meant, "six of one, half-dozen of the other"? It is fairly humorous, however, to say, "72 of one thing, .5 of the other..."

Re:If you're going to be this generic... (5, Funny)

sammy baby (14909) | more than 7 years ago | (#14762697)

My issue with databases and all that is that they are not abstract enough. Either one must create a new table when one wishes to implement a new feature, or one must develop some extremely generic database that is hard to search.

Well, you could always create a single-table database. Call the single table "Stuff," put a generic autoincrementing key on it, and give it two more columns: a type identifier and a serialized object that contains all the data.

Of course, you could also stab yourself in the eye. Might be preferable.

Experiences (5, Interesting)

truthsearch (249536) | more than 7 years ago | (#14762343)

It's a huge step forward for OO development in PHP.

BUT it's still got all the crud of PHP4. For those transitioning from PHP4 objects one great feature is the new warning when using the older style of classes. However all of those things people find quirky about PHP4 still exist. For example, now you can force a function parameter to be a certain type of object, but not a basic type. You still can't even fully overload a function.

My view is that it's two steps forward and one step back. They need to consider deprecating features and making a php.ini option to not allow the use of any deprecated features.

Re:Experiences (0)

Anonymous Coward | more than 7 years ago | (#14762496)

Give me real threading and we'll talk. Until then, php will remain the scripting language for the quick-and-dirty get it done yesterday crowd and we'll worry about scaling it later.

Re:Experiences (3, Insightful)

Tenareth (17013) | more than 7 years ago | (#14762906)

Yeah, the inability to scale is the primary reason all the porn sites use it...

And why we have a lot of high traffic sites that have no issue with it...

Threading != Scalability. Threading is only needed if you do certain types of tasks that need it.

In programming, there is no silver bullet, there are lots of tools suited for different jobs, PHP fits in a lot of those places, Java in others, other languages elsewhere. Threading isn't a "Oh, I'll multithread it, that'll make it faster" type of magic button.

Re:Experiences (1)

JabberWokky (19442) | more than 7 years ago | (#14762513)

You still can't even fully overload a function.

How so? I'm not saying that PHP classes are fully OO, but overloading, AFAIK, is completely supported.

They need to consider deprecating features and making a php.ini option to not allow the use of any deprecated features.

If backward compatibility could be turned on and off, I'd prefer some sort of php_compatibility( COMPAT_PHP4 ) type call, coupled with a error_reporting() flag that could be used to flag obsoleted things in order to make it easy to bring things in a old library to the latest version. It is a very "PHP-ish" way of doing it, especially if include and require could have a compatibility flag passed: require_once("new/mylib.php"); require_once("old/mylib.php",COMPAT_PHP5). (The "new" lib wouldn't need a COMPAT flag because it would presumably state its own compatability at the beginning).

At that point function names could be standardized and compatibility modes just provide aliases (the way a couple function names are already done) back to the old name... with a warning being raised if you have the E_OBSOLETE (or similar) flag on.

Not sure how it would work internally for more complex things changed between versions... maybe some compatibility will just have to be dropped.

--
Evan "just thinking out loud"

Re:Experiences (2, Informative)

T-Ranger (10520) | more than 7 years ago | (#14762649)

You have the choice of either type hinting OR function overloading. If you use type hinting, you have to pass that function exactly those types (and not a null, either) . And its not realy function overloading; you, as the developer, need to resolve what your being passed. Most everything else that allows overloading, you write multiple functions, and the compiler decides what to do.

Re:Experiences (1)

killjoe (766577) | more than 7 years ago | (#14762998)

Although technically there is nothing python can do that php can't I am afraid PHP usage will continue to decline till they fix their namespace problems and make an effort to standardise their function calls.

PHP (0, Flamebait)

Jeian (409916) | more than 7 years ago | (#14762347)

PHP: The Language For People Who Can't Code Perl

Re:PHP (1)

drpimp (900837) | more than 7 years ago | (#14762365)

Or people that can't wait for Perl 6 to come out.
Or people that don't want to use Python for web interfaces.

IMHO, Perl is too cryptic

Re:PHP (-1, Troll)

Anonymous Coward | more than 7 years ago | (#14762372)

Perl: The language for people who are to stubborn to move to Ruby.

Re:PHP (0)

Anonymous Coward | more than 7 years ago | (#14762422)

PHP: the language for the people who want to write web applications or simple scripts and do not like Perl's fugly syntax.

Re:PHP (0, Flamebait)

Anonymous Coward | more than 7 years ago | (#14762434)

Ruby: The language for people who can't use microsoft front page.

Infighting between PHP and Perl? (1)

xxxJonBoyxxx (565205) | more than 7 years ago | (#14762436)

Infighting between PHP and Perl? Really.

Once you get to know a couple of other programming languages, PHP and Perl look quite similar indeed. (Kind of like VBS and ASP, Java and C#, C and C++, etc. are similar.)

Re:Infighting between PHP and Perl? (1)

Foofoobar (318279) | more than 7 years ago | (#14762481)

Nah... the PERLies are just jealous that PHP continously outranks them on the Tiobe index and are the number one Apache module. The popular kids are always the target of envy.

Re:Infighting between PHP and Perl? (2, Funny)

shobadobs (264600) | more than 7 years ago | (#14762654)

No, they are like completely different. About the only thing they have in common is $ in front of scalar variable names, some is-it-a-string-or-is-it-a-number situations, and C-style loops and if statements.

Re:Infighting between PHP and Perl? (1)

akheron01 (637033) | more than 7 years ago | (#14762882)

Speaking out of personal experience this is wrong, simply wrong, I recently had to port a medium sized project for my company from Perl to PHP, and other than a few minor syntactical tweaks and changing the names of built-in functions I was able to use pretty much the exact same code, many algorithms went over with ZERO changes.

Re:Infighting between PHP and Perl? (0)

Anonymous Coward | more than 7 years ago | (#14763267)

That must have been some pretty aweful perl code. Nearly everything I write cannot be straight ported to PHP because its missing basic language features, like lexical scope.

Re:PHP (4, Funny)

Ford Prefect (8777) | more than 7 years ago | (#14762461)

PHP: The Language For People Who Can't Code Perl

Oh, but everyone (and everything) can code perl - the trick is to hit the keys in a sufficiently random manner.
A$u^UD&KRWTuKUI^R&54$%A%ERYTi:",<%$E^%L<E%@$U%^*E
There. That's either a full-featured web-browser, or a worm which will destroy the entire internet. I don't really dare to run it... ;-)

Re:PHP (4, Funny)

deep44 (891922) | more than 7 years ago | (#14762524)

Can anybody else read this comment? My browser keeps crashing..

Re:PHP (4, Funny)

nbritton (823086) | more than 7 years ago | (#14762796)

@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{
@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q *=2)+=$f=!fork;map{$P=$P[$f^ord
($p{$_})&6];$p{$_ }=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[ P.]/&&
close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];sleep rand(2)if/\S/;print

Ouch (0)

Anonymous Coward | more than 7 years ago | (#14762977)

All I wanted was a simple and effective tool for iterating over a directory of files (recursively), and looking for content that matches the argument...

No, wait...

All I wanted was an obtuse, terse, un-commented, obfuscated, half-mile-long script that uses one-letter variables, one-letter function names, has 87 module dependencies, and can only be run in one version of perl compiled by a Hungarian from Walla-Walla Washington on an 8086 running DOS 1.0 on Tuesday, March 3, 2001 at 0413 GMT -6... preferably with the entire script written in one line of code with no extra white space and has no wrapping to fit a little term window...

No, wait...

Re:PHP (0, Flamebait)

A beautiful mind (821714) | more than 7 years ago | (#14762525)

How true.

People who don't know Perl are doomed to reinvent it. Badly. ;)

Re:PHP (1)

iBod (534920) | more than 7 years ago | (#14762641)

Oh, I see!

They are doomed to reinvent a bastard mishmash of TATMFWTODI (There Are Too Many F*ing Ways to Do It).

Perl was a very bad reinvention and a cludge of almost every C-style shell script language with several old kitchen sinks thrown in.

Ah! Such elegance! I can see Perl is the only way forward! [sigh]

Any fool can code Perl... (4, Insightful)

iBod (534920) | more than 7 years ago | (#14762529)

Any fool can code Perl, just like any fool can code PHP/C/Java/VB/Smalltalk/COBOL etc. etc.

Anyone can write code, but very few can write really great code, that reduces the problem to the essential elements and uses the simplest approach to the problem, with the tool (i.e. language) in hand.

You can write shit code in ANY language. You can also write good code in ANY language (within the limitations of the language).

What you're saying is like "Spanish for People who can't speak in German".

It's nonsense and insulting at the same time.

You need to express yourself or solve the problem within the framework of the language you have.

You might choose a different language for a particular task, but if the language is a given, a good poet (or programmer) will make the best of it.

A better language doesn't make one a better programmer (or poet).

Re:Any fool can code Perl... (1)

Unski (821437) | more than 7 years ago | (#14763083)

Eloquently-put, I wish I had your patience..

Re:Any fool can code Perl... (2, Insightful)

panaceaa (205396) | more than 7 years ago | (#14763143)

A better language doesn't make one a better programmer

I agree with this point for good programmers, but for inexperienced programmers a better language can certainly make one a better programmer. The common example is VB, which allows people with basically no programming experience to develop simple applications. But even Java's success in enterprise software is due to the proliferation of design patterns such as EJBs and MVC -- which have basically been ingrained into the language itself. These patterns allow a team of inexperienced programmers to separate complex projects into manageable pieces and use well established integration points.

Without Java's patterns many teams would be unable to come up with coherent systems in a timely manner. Projects would instead stumble while developers try to invent new architectures and learn from their mistakes. In addition, the adoption of these shared principals makes it much easier for new developers to jump into a project since the underlying design is likely similar to previous projects -- even if the code itself is absolute crap. Therefore the programmer who coded the absolute crap IS a better programmer since his code is still maintainable due to the choice of language.

Re:PHP (4, Funny)

Unski (821437) | more than 7 years ago | (#14762531)

Or actually, the language for people who want a specific tool for a specific job. What is it with this tedious Perl clique on Slashdot? There are, I presume, plenty of other language-based cliques on /. , however the most vocal ones always seem to be the Perl-mongers. They're the ones who seem to pipe-up the most regardless of topic.

And, for some reason, I'm always left with this mental image of a tall, pasty elder geek sitting in that proverbial Mom's Basement, pulling on his long pointy beard whilst his Gentoo box spends it's 28th hour compiling a boot-loader or something, smirking as he sees his, ahem, 'Perl of Wisdom' slide down the Slashdot page like a turd in summer.

I just fucking hate you, why bother posting at all?

Perl: The Language for People Who Can't Be Arsed to Investigate the Right Language For The Task At Hand.
Perl: 'Cos You Never Really Moved On.
Perl: Why Use the Standalone Screwdriver When There Is A More Fiddly One Attached To This 52-Way Swiss Army Knife?

* Retrieves dummy and calms down *

Re:PHP (1)

eargang (935892) | more than 7 years ago | (#14762581)

Could be worse. Could be rubyists. Them folk is rabid, I tell ya.

Re:PHP (1)

WilliamSChips (793741) | more than 7 years ago | (#14762802)

The only package on Gentoo that takes anywhere near 28 hours to compile on my computer(900MHz Duron, not very good but not very bad either) is OpenOffice.org. Oh how I hate OO.o! And Perl is only good for ten-line regex scripts. :P

Re:PHP (1)

Unski (821437) | more than 7 years ago | (#14762911)

I just don't know where to begin on this one!!! :p

I do like that Gematriculator thingumibob though..this thread is apparently 43% evil!!!! Mwa ha ha ha...

Re:PHP (1)

woolio (927141) | more than 7 years ago | (#14763001)

What is it with this tedious Perl clique on Slashdot?

Dunno... Make most of the "out of work" coders are Perl programmers.

Goin dynamic? Database Object classes? (1)

Dragoonkain (704719) | more than 7 years ago | (#14762368)

This article is all nice and well, but last time i checked there were PLENTY of OO DB connection classes in php. Why does this article decide to example off of that? http://pear.php.net/ [php.net] has a fine db class, and as far as i know php 5 has a whole new set of connection objects, specifically crafted for each type of database. If your going to show 'new dynamics of php5' at least choose somthing that has'nt been done already so we can make real sense of it.

Woe is me. (1)

MaXiMiUS (923393) | more than 7 years ago | (#14762401)

Too bad my bloody host is still using Fedora Core 2, with PHP 4 >_>

always remember (0)

Anonymous Coward | more than 7 years ago | (#14762430)

Linux is NOT backwards compatible.

OOP (5, Insightful)

onion2k (203094) | more than 7 years ago | (#14762409)

I'm a fan of using objects in the right place .. but to suggest they increase the functionality of a language is simply wrong. They allow for better (well, different) organisation of code, easier reuse, and improved encapsulation over procedural or functional coding styles, but they don't actually allow you to do anything that can't be done using any other approach. The functionality of the language remains the same.

Re:OOP (1)

truthsearch (249536) | more than 7 years ago | (#14762465)

Very true. And specifically in PHP's case objects provide encapsulation that's otherwise impossible. If they simply provided modular scope (similar to Python) I probably wouldn't use PHP objects half as often.

Re:OOP (1)

Tablizer (95088) | more than 7 years ago | (#14762602)

They allow for better (well, different) organisation of code, easier reuse, and improved encapsulation over procedural or functional coding styles,

As a long-time OOP skeptic and criticit, I have not seen very convincing examples of of these (except maybe for systems software). I don't want to start an OOP war, but am just suggesting that people not use objects just because somebody says to (unless they are your boss and order you).

"Organization of code" tends to be very subjective. What makes one brain happy will bother another.

"Easier reuse" - This is utter nonsense. Show me an example. Reuse has fallen out of favor as the main OOP claim even among respected OO guru's.

"Encapsulation" - In certain circumstances it may reduce the chance of putting the wrong "handle" with the wrong stuff, but that is not a common error I encounter anyhow and may not be a factor in dynamic languages. Some will suggest encapsulation makes adding new "sub-types" easier, but the flip side is that other kinds of changes are harder, especially adding new operations to existing classes. Further, changes that don't grow in a hierarchical fashion tend to muck up under OO encapsulation. It depends on the grain of the change. It is not a free lunch. Thus, I have stamp this one "subjective preference" or "depends on domain".
         

Re:OOP (4, Insightful)

IgnoramusMaximus (692000) | more than 7 years ago | (#14762828)

I don't want to start an OOP war, but am just suggesting that people not use objects just because somebody says to (unless they are your boss and order you).

I am with you on this one, although, unlike you, I used to be swept up at one time in all the early OO hype to a degree (back in the Smalltalk days - which by the way is probably the only coherent OO environment), only to realise, by experience, that it was for the most part just that: unsubstantiated hype. Object Orientation has applications, notably in situations close to its original aims of simulation of physical universe (as in the Simula language which started it all), which in modern software is found in things like PC games. But this paradigm has been overused, abused and stretched beyond its breaking point to try to cover all possible cases, no matter how ill fitting. And in the process it has consistently failed to deliver on most of its promises (other then to pad pockets of various charlatans and OO "framework, IDE, grill and taco stand" makers). My experience has thought me that contrary to what OOP priests wish us to believe, "complexity hiding" (usually by masking it by more OO-gunk complexity) is not the answer to reusability, cooperative maintenance and so on. The answer is: simplicity. That is the most maintainable code is the one which can be fully understood, with ease, by the programmer. OOP does not do that. In fact it introduces a whole new gamut of problems dealing with the hidden workings of pyramidal heaps of classes found in any OOP "framework", each with its own weird quirks and inconsistencies, from which you are supposed to "derrive" your own, as long as you adhere to a million of unwritten and poorly documented rules of use of these, supposedly, "reusable" and "extensible" components. Not to mention that it actively encourages creation of massive, incomprehensible class jungles as one can easily see in places like the JDK.

Speaking of PHP, its success can be attributed to its simplicity, ease of use and short learning curve. If they keep continuing to "innovate" new piles of ever more trendy crap into the language, it will soon (already is?) lose this advantage. It won't be long before someone comes up with another simple server-side language to replace the morass and the enthusiatic crowds will move onto this new "lighning fast, low footprint" language and begin to "improve it". Rinse, repeat.

Re:OOP (2, Insightful)

ctr2sprt (574731) | more than 7 years ago | (#14762973)

If you're a programmer, I guarantee that you're using OOP even if you don't use an OOP language.

Consider the Unix read() function, which can read from any file descriptor: regular file, block or character special, socket, and so on. If you were to write such a function in C, you'd write some code to determine the underlying type of descriptor. Then, based on that type, you'd call a helper function - read_file(), read_special(), read_socket() - to perform the actual read.

Guess what? That's OOP. The file descriptor is the object. The code at the top of read() is determining the object type (or class). And the helper functions are class methods. If this is a big project, odds are you'll put all the helper functions for sockets in socket.c, for files in file.c, and so on. And there we have encapsulation (of the namespace variety) too.

As noted many times, you can write an OOP in any language. It's just easier to do it in a language that's designed for it. The compiler (or interpreter) does more of the work for you. For instance, you don't need to write the type-checking code, nor do you need to pollute your namespace and worry about collisions. And if you later want to add a new descriptor type, such as for a userland memory-based file, all you need to do is write a new class. All the functions or classes which operate on the other descriptor types will work, unmodified, on the new type. (That's the real code reuse: on the application side, not the library side.)

Re:OOP (4, Insightful)

IgnoramusMaximus (692000) | more than 7 years ago | (#14763097)

Let me take this silly argument to its full comical potential:

If you're a programmer, I guarantee that you're using SEP (Spiritual Extrusion Programming) even if you don't use a SEP language.

Consider the Unix read() function, which can read from any file descriptor: regular file, block or character special, socket, and so on. If you were to write such a function in C, you'd write some code to determine the underlying type of descriptor. Then, based on that type, you'd call a helper function - read_file(), read_special(), read_socket() - to perform the actual read. Guess what? That's SEP. The file descriptor is the Spititual Manifestation of a Concept. The code at the top of read() is determining the object type (or Spiritual Element). And the helper functions are Spiritual Invocations. If this is a big project, odds are you'll put all the helper functions for sockets in socket.c, for files in file.c, and so on. And there we have Spiritual Encapsulation (of the namespace variety) too.

As noted many times, you can write an SEP in any language. It's just easier to do it in a language that's designed for it.

And so on, etc.

Newsflash: all of the concepts you describe are 1) long in existence before your favourite paradigm arrived on the scene so that you can try to contort them into it, and 2) can be interpreted ad infinitum with any of the millions of "paradigms" one can concoct on the spot. That is because your paradigm is merely a perspective and not an universal (and only) truth. The whole point of abstract formulations, such as computer software, is that they can conform to nearly infinite number of perspectives and can be projected onto the real, physical universe in an equally large number of ways, which is what makes this whole Information Technology thing so powerful.

But I fear that long after OOP has been relegated to the dusty bin of history, some ctr2sprt of the future will still argue about how you are really always writing "Quantum Parallax" code, even if you are you are not ...

Re:OOP (1)

Tablizer (95088) | more than 7 years ago | (#14763140)

I have already agreed that OOP may work well in "systems software". However, OOP modeling does not seem to do very well in biz apps. Extrapolating from device drivers to business "objects" seems to fall flat on its face 90%, and one cannot guess ahead the good 10% of the time such that one might as well not try to OO them.

There is a reason most of the examples demonstrating OO's ability are in the domain of systems software and device-driver-like doodads. It is not cooincidence. OO flunks biz and that's the honest naked truth. (More precisely, nobody has figured out how to model biz well in OO.)

There are also a fair amount of GUI examples, but the best GUI frameworks are mostly declarative IMO, not in-code. In-code was fine when the learning curve for GUI's was new in the 80's, but we now know enough to declaraterize most GUI frameworks today such that they are not language-specific, or less lang-specific.

Another problem-spot for OOP is inter-language libraries. Declarative-leaning techniques are more transferrable across languages. OOP tends to be behavioristic.
         

Re:OOP (2, Interesting)

yintercept (517362) | more than 7 years ago | (#14762985)

OOP is transcendant. OO programmers are on a higher level of existence than procedural programmers. When I OOP, I am charged revolutionary spirit. It feels great! I love thinking in objects and discussing patterns while smoking a pipe in an easy chair.

Sadly, the main use for PHP is to jam out a script to get a job done. Much as I love objects. I can't help but notice that my primary use of PHP is to grab a string of data from MySQL, pack some HTML around it and present the string to a web server. Writing code to translate a string from a database into HTML is not substantially enhanced by OOP.

When I want a full object model ... I really don't want to use a scripting language.

As much as I love the revolutionary spirit of OOP, I worry that maybe there's a part of me that is still just petty bourgeoisie. Even with PHP 5, I find that my PHP code comes out in the form of procedures. The game of wrapping a string from a database in HTML code is easier with procedures.

It makes me feel shamed, but, I still keep writing procedures.

Re:OOP (1)

Tablizer (95088) | more than 7 years ago | (#14763202)

OOP is transcendant. OO programmers are on a higher level of existence than procedural programmers. When I OOP, I am charged revolutionary spirit. It feels great! I love thinking in objects and discussing patterns while smoking a pipe in an easy chair.

Unfortunately this feeling has been difficult for OO proponents to translate into public demonstrations, metrics, and scenarios (at least for some common domains). This repeated difficulty to objectify perceived benefits is one of the reasons why I think paradigms are largely subjective: they model individual brains better even if they don't necessarily model the external world better (in any measurable way).

A couple of times scenerios were put forth to show how OO better bends to change. However, I fealt the change scenearios selected were not very represented, and it turned out that we perceived change itself differently. You can't compare change scenarios if both parties don't even agree on how things tend to change. People just plain think differently from each other. At best we can document our givens/assumptions, and if the reader disagrees with the givens, then so be it.
         

Re:OOP (1)

Fahrenheit 450 (765492) | more than 7 years ago | (#14762716)

They allow for better (well, different) organisation of code, easier reuse, and improved encapsulation over procedural or functional coding styles

And I'm not even sure I'd go that far. Consider, for example, OCaml's module and functor system which allows for a very high degree of code reuse, and a type of encapsulation. It certainly allows for information hiding and a tight type-based relationship between data and functionality.

Hosting services stuck on PHP4 (4, Informative)

cknudsen (891397) | more than 7 years ago | (#14762424)

I'd love to take advantage of some of the PHP5 features. However, most hosting services are still stuck on PHP4. How long has it been now? I am the project manager for WebCalendar, and just like during the transition from PHP3 to PHP4, it's going to be some time before we can drop "legacy" support for PHP4 and take advantage of the cool new features of PHP5. So, for now, WebCalendar and other open source apps will have to stick to PHP4.
FYI.... PHP developer articles updated daily:
http://www.devpointer.net/browse.php?l=p&t1=1 [devpointer.net]
RSS:
http://www.devpointer.net/browse.php?l=p&t1=1&fmt= rss1 [devpointer.net]

Re:Hosting services stuck on PHP4 (0, Offtopic)

Slushie31 (857901) | more than 7 years ago | (#14762991)

Check out Telana [telana.com] . It's a rather good (and cost-effective) PHP5 host, and I've been using them almost since PHP5 was rolled out, for exactly this reason -- noone else had either PHP5 hosting or good PHP5 hosting. Right now he's running 5.0.4, but once he determines a release is "stable", he upgrades.

Re:Hosting services stuck on PHP4 (1)

jZnat (793348) | more than 7 years ago | (#14763130)

How do you determine the "stability" of a PHP release? Unless there are regressions between releases, each new release is technically more stable than the last (hence the point of incremental releases).

Not The Best Choice For Maintainable Code (3, Insightful)

tres (151637) | more than 7 years ago | (#14762432)

From the article:


Dynamic objects have a lot of power, but they also carry significant risk. First, the complexity of classes increases tremendously when you start writing magic methods. These classes are harder to understand, debug, and maintain. In addition, as integrated development environments (IDEs) become more intelligent, they may experience problems with dynamic classes such as these because when they look up methods on a class, they won't find them.


This is what I was thinking the entire time I was reading the article. I mean, it's one thing to have to whip up some small project for yourself, it's another to build a project that is maintainable by a group of people.

I'd bet that Brian W. Kernighan and Rob Pike (The Practice of Programming [bell-labs.com] ) would probably recommend against using it. It doesn't provide for clarity, nor does it simplify, it just makes things "easier" for the guy that writes the original code.

Re:Not The Best Choice For Maintainable Code (1)

prockcore (543967) | more than 7 years ago | (#14762607)

It doesn't provide for clarity, nor does it simplify, it just makes things "easier" for the guy that writes the original code.

What? I'd argue that:

$customer=new Customer();
$customer->name="Bob";
$customer->phone="555-1234";
$customer->insert();

is much more clear than
$conn=mysql_connect("localhost","user","password") ;
mysql_select_db("customers",$conn);
mysql_query("insert into customers (name,phone) values ('Bob','555-1234')",$conn);
mysql_close($conn);

It's cleaner and easier to read.

Re:Not The Best Choice For Maintainable Code (1)

T-Ranger (10520) | more than 7 years ago | (#14762678)

You are comparing different things. Its not a question of if mysql_() or objects are called, but how the object is implemented.

Re:Not The Best Choice For Maintainable Code (1)

lewp (95638) | more than 7 years ago | (#14763191)

You're right. Your OOP interface is simpler than that second mess of code, which would actually run. Now, add all the stuff you have to write first for the OOP example to work and we'll have a fair comparison.

Nobody's saying everything has to be done inline, what some folks are saying (and it's reasonable, IMHO), is that there's lots of places where OOP gets in the way more than it helps. Simple functions could abstract your second example out to where it's just as simple as the first example, without having to worry about classes at all.

I Prefer The Class Generator (1)

aaronvegh (546815) | more than 7 years ago | (#14762438)

Cool article, but the first paragraph where he's deciding to write a single class to handle any database table, while cool, isn't as cool as PHP Object Generator, the tool I use to handle my databases. Ch-ch-check it out: Right here [phpobjectgenerator.com] . It's sweet.

Okay, back to nerding.

Kinda Like Ruby (3, Insightful)

pkulak (815640) | more than 7 years ago | (#14762448)

So, it's got some of the features of Ruby now, plus a whole lot of crap dragged in from PHP 3 and 4 inluding that crazy mishmash of a function library? Boy, sign me up.

I would like to be the first to say... (4, Funny)

Yuioup (452151) | more than 7 years ago | (#14762452)

"welcome to 1967".

http://en.wikipedia.org/wiki/Simula [wikipedia.org]

Y

Re:I would like to be the first to say... (1)

MobyTurbo (537363) | more than 7 years ago | (#14763277)

"welcome to 1967"
Seriously though, OOP is *not* a new idea. Alan Kay, inventor of Smalltalk, wrote an article about OOP in the 80s entitled "back to the future", because amongst people who knew about such things, OOP was not a revolutionary idea even then. What's new is its popularity.

Alternatives to consider (1)

Tablizer (95088) | more than 7 years ago | (#14762485)

Here are two other approaches to consider:

1. Use maps (associative arrays) instead of objects. If it is mostly just attributes, then the difference will be small. Map syntax is usually more compact than object syntax, keeping the code clean.

2. Create a data dictionary table where field attributes and even code or function calls (used with eval() function) are kept. However, you will need to find a good table browser to enter all that conveniently. A data dict table may not always be the most efficient from a machine standpoint, but can make for good RAD if used well.
     

Crap... (4, Funny)

A beautiful mind (821714) | more than 7 years ago | (#14762509)

I've clicked to another tab to browse at some other site and then I've seen suddently:

"Slashdot | Going Dynamic with PHP"

...as the title of the Slashdot tab. It gave me the creeps until I remembered whats the article about. Phew.

OO PHP 5 == Java Lite (and slightly broken) ?? (0, Insightful)

Anonymous Coward | more than 7 years ago | (#14762546)

Comments that a friend made: PHP 5 -- when using the OO -- looks a lot like Java, except no real threads, no security (sandbox), no WeakReferences and other GC niceties. Enjoy!

Re:OO PHP 5 == Java Lite (and slightly broken) ?? (1)

jZnat (793348) | more than 7 years ago | (#14763145)

PHP will eventually get all that J2EE goodness. Take a look at the trunk (PHP 6) for examples.

Interesting, but ... (2, Interesting)

isolationism (782170) | more than 7 years ago | (#14762566)

... There hasn't exactly been widespread adoption of PHP5 at commercial hosting interests, has there. I see PHP's greatest strength being its widespread adoption, not its OO model -- and it doesn't do a lot of good to develop using a technology that is effectively unavailable to host your application unless you want to set up your own co-located server to do it (e.g. even top-notch managed services like Rackspace still come with PHP4).

Perl is another alternative, and admittedly a pretty popular installation (I imagine anywhere that offers PHP hosting also offers Perl) -- but for someone like me who wants to do the occasional scripting the language is not exactly ideal -- nor is it especially easy to read someone else's code. I think Perl developers are incidentally the most "guilty" party of poorly commented code in FOSS projects, which doesn't help matters.

As a designer and occasional scripter I was interested in learning more PHP at one time, but now I feel as though it's a bit of a dead end, especially for "bigger" projects. Learning Python seems to be time better spent at this point; I can run a native interpreter as well as Java and .net based interpreters to handle more "enterprise-sized" projects; Python has a stronger OO foundation than PHP in existing versions, is designed to easily integrate with C modules, and reads easily. It's also shown itself to be equal to a broad spectrum of applications from commercial tax forms software (QuickTax) to web application frameworks (Zope) to HTPC frontends (Freevo) to P2P software (BitTorrent).

As for PHP, roll me over when version 5 is standard across the board and I'll consider taking another look at it.

Re:Interesting, but ... (1)

Tablizer (95088) | more than 7 years ago | (#14762673)

but now I feel as though it's a bit of a dead end, especially for "bigger" projects. Learning Python seems to be time better spent at this point; I can run a native interpreter as well as Java and .net based interpreters to handle more "enterprise-sized" projects;

This depends on how one views "bigger projects". Java projects tend to model the domain nouns with lots of OOP classes, and to do this one tends to need "one big executable", or at least something that manages them like one.

However, if one goes more or less against the database and use the DB schemas as the "noun model", then difference between "big" projects and small ones is small because one focues on one action/event at a time regardless of how big the DB is. (And with any shared libraries, of course). A small script can process info from a small database or a huge one with billions of records. It all depends on whether you use objects or the DB for your "noun model".

In some cases it makes sense to create DB views to simplify certain kinds of queries.
       

Questionable code pieces.. (1)

guice (907163) | more than 7 years ago | (#14762609)

I have to question the writer's competence in PHP. For one, take:
$book->{'title'} = "PHP Hacks"; $book->{'author'} = "Jack Herrington"; $book->{'publisher'} = "O'Reilly";
pretty Perl esque. That even work in PHP? I never would have figured. I've personally kept my Perl etiquettes very sepereate from PHP etiquettes. Then you have his DB assignment:
$db =& DB::Connect( $dsn, array() );
In PHP5 all objects are passed by reference, making =& an E_STRICT warning.

Linking some form of programming and variable naming convention would have been nice, too. He doesn't have to go into detail, just lay mention to it. Something like "Just fyi, I follow X conventions when naming my classes, variables, etc..."

Then you tack on the complete lack of comments! ^_^

Re:Questionable code pieces.. (1)

jZnat (793348) | more than 7 years ago | (#14763161)

What's wrong with a reference to a reference? If I wanted to use the C code "int *******i;", I could, and nothing would bitch at me (other than humans). Besides, =& looks better as it distinguishes an object from a primitive, and it looks like a confused emoticon.

DB_DataObject (2, Informative)

schmidt (69858) | more than 7 years ago | (#14762735)

There is an implementation of this idea (and more) in PEAR's DB_DataObject package:

http://pear.php.net/manual/en/package.database.db- dataobject.php [php.net]

Too little too late (1)

zardo (829127) | more than 7 years ago | (#14762774)

I was following PHP5 development until the RC1 deployment, and I was disappointed. There wasn't really much, I yearned for a new, truly OO language. Luckily, about the same time, Ruby on Rails was getting a lot of attention and I checked that out, now I couldn't be happier. I do some contract work in PHP4 and PHP5 sometimes, and I just get this sick feeling. Honestly I'd much rather program in Perl than PHP.

Dynamic Methods + Dynamic Tables = Rails? (1)

Salamanders (323277) | more than 7 years ago | (#14762838)

Combining the dynamic getters and setters with the PEAR DB_Table (http://wiki.ciaweb.net/yawiki/index.php?area=DB_T able [ciaweb.net] ) class would truly kick ass - full run-time definition of tables, HTML_QuickForms, and all that other whiz-bang stuff. No more .sql scripts anywhere, hell, no more SQL anywhere!

Can RoR do that? (Honest question, I'm a PHP guy, but have heard a lot about RoR)

DB_Table is worth checking out.

Six more ways to make it more dynamical (1)

MasterC (70492) | more than 7 years ago | (#14762887)

The one thing I was disappointed about this article is that it doesn't make a "describe $table" call to get the fields for you. You could then extend DBObject to like DBO_customer and the constructor would yank "customer" out of the class name. So then all you really have to do is extend and rename and that's it. No need to directly pass the table name to the constructor.

Secondly, by modifying the load function to accept an array of id's and implementing the Iterator interface, one can use the object in a foreach loop to iterate over each customer (perhaps by implementing DBObject::current() to instantiating a new object and populating it with data for a specific customer thus maintaining objects within the foreach loop). (The trick is to tie the original object into the new one so a data update in the new object is reflected back to the original.) Maybe even add in transaction support on update & delete calls.

Thirdly, if you add in "dirty" and "new" flags to each row stored in the object then you can combine insert, update, & delete calls in a single DBObject::sync() call (again wrapped in a transaction if you wish).

Fourthly, don't forget __unset() and __isset() to remove or check for fields.

Fifthly, store the other columns from the describe call and do validation and/or type conversion automatically.

Finally, __sleep() and __wakeup() would be useful for serializing objects to a session or something. That one's easy though: just serialize() your fields array and unserialize on wakeup.

One more difficult step I have yet to try is supporting joins (perhaps you want to load an object with a customer and all of their orders) which would save the need to use 2+ objects.

Interesting approach, though I wouldn't use it (1)

TLLOTS (827806) | more than 7 years ago | (#14762945)

While the approach in the article does appear to be quite good for rapid code generation, I personally wouldn't touch it with a ten foot pole if I had a choice, though I was unfortunate enough to have to work with such a setup recently.

The problem with this kind of setup is that while it works well for simple work, the moment you try and do something more complex, you'll find you have to fight against the API, and the code will end up being a mess in order to do a task that should be quite simple.

Naturally I have a somewhat different approach that's somewhat weird, but I've enjoyed great success when using it. I have one database object called 'database' funnily enough ;) Inside this database object there are four other objects, select, insert, update & delete. Now, each of these four objects aren't anything special, they're simply wrappers around methods of a particular type (select queries go into select for example).

To give an example, where the author in the example wrote

$book->{'title'} = "PHP Hacks";
$book->{'author'} = "Jack Herrington";
$book->{'publisher'} = "O'Reilly";
$id = $book->insert();

I would simply write

$book_result = $database->insert->book("Jack Herrington","O'Reilly");

This method will return a result object, from which I can retrieve the id simply by typing

$book_result->fetch_insert_id();

Now how does the internals of this work? I won't say, simply because it doesn't actually matter, which is the whole point of this kind of setup. It provides a very simple API, so that in the back I can make it work however I want, allowing me to easily switch in different databases, or if I wanted to I could make it work with flat text files. This way I keep all my messy SQL contained in one area and I don't see it anywhere else, making it much easier and cleaner than the method offered in the article. However, my method will require more work to setup initially, and naturally it won't automatically adapt to changing database tables... though I have to wonder about the quality of a project wherein the tables are changing frequently, that's the kind of thing one should have planned out from the beginning.

That said, I'm sure there is some value in setups like the one mentioned in the article, and my own database abstraction code is hardly perfect as I'm still something of a beginner at programming in many ways.

Re:Interesting approach, though I wouldn't use it (1)

jZnat (793348) | more than 7 years ago | (#14763170)

Does this have anything to do with OSQL?

No Application Scope (1)

chrisbeach (887853) | more than 7 years ago | (#14763012)

PHP 5 does indeed have more "complete" support for object orientation. The new XML/SOAP libraries are also a welcome addition.

However, IMHO it is still lacking one crucial feature - application scope for variables. Most of the competing platforms (ASP, JSP etc) allow a website to operate with shared memory (between sessions), but in PHP this is a glaring omission.

Try creating an AJAX chatroom in PHP. You'll find yourself stuck between a rock and a hard place - either messing around with cumbersome file I/O or hammering the DB with lots of connections and requests.

Now try it in JSP, for example - simply put a couple of objects into application shared memory and the task is accomplished elegantly.

I love coding PHP but I miss application scope.

PHP: Prostitute Hard Powerful (0)

Anonymous Coward | more than 7 years ago | (#14763096)

PHP: Polish Howling Perfect
  PHP: Polish Heavy Perfect
  PHP: Prostitute Hard Powerful
  PHP: Putty Hypertext Preprocessor
  PHP: Purr Hobo Prostitute
  PHP: Protection Hairy Poop
  PHP: Puntme Homosexual Puntme
  PHP: Polish Homo Pimp
  PHP: Poop Hot Protocol
  PHP: Purr Homeland Pipebomb
  PHP: Protection Hot Programmer
  PHP: Pope Hypertext Perfect
  PHP: Prostitute Hoard Protection
  PHP: Piles Hypertext Protocol
  PHP: Pooping Hard Powerbook
  PHP: Pimp Huge Php
  PHP: Powerbook Horrible Piles
  PHP: Poop Howling Pope
  PHP: Protection Homeland Powerful
  PHP: Pipebomb Hitler Plop

LOL (0)

Anonymous Coward | more than 7 years ago | (#14763105)

LISP, bitches!

OO and PHP? What's the fuss.. (2, Interesting)

PietjeJantje (917584) | more than 7 years ago | (#14763137)

I've almost never seen OO been put to good use with PHP. It's used exclusively as a tool for the developer to write, as the author puts it, "more maintainable code". However, with the (lack of) real complexity and sprawling code bases which accounts for most web sites, it just adds complexity by adding a "system" for the developer.
Forgetting the developer, it adds nothing, and has a major impact on speed and memory. It adds nothing as in 99,9% of the times I've seen it used, it's 1) stateless and 2) a collection of single object instances (one page, one database connection, one user, etc.).
In a lot of cases, I think the programmers would have been a lot better of just seperating the logic in functions and few files, and then he can understand his own code after a few months off it.

am I the only one... (1)

skogs (628589) | more than 7 years ago | (#14763271)

that actually thought it was a well done article?

Seems a bit better than some of the journalist's moronic rantings that I've seen lately on /.

Good food for thought, good examples, good examples of the new functions that replace some of the fubar functions in 3 & 4.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>