Going Dynamic with PHP

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

Comments

PHP's Comeupance

[(1 -sqrt(5))*(2**-1)]

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.

Re:PHP's Comeupance

[(1 -sqrt(5))*(2**-1)]

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

[Hal_Porter]

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.

Re:PHP's Comeupance

[Anonymous Coward]

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

[Anonymous Coward]

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

[Holi]

Sorry, but pictures don't count.

Re:PHP's Comeupance

[sweetnjguy29]

Learned a new word: lacunæ (latin for lake) -- in this context, a gap. Well done, sire!

Re:PHP's Comeupance

[sasdrtx]

Poser. "surpised"?

Re:PHP's Comeupance

[Anonymous Coward]

Poser. "surpised"?

Come, bitter trough; that's what's referred to in calculus as a "reducible" error.

Re:PHP's Comeupance

[hao2lian]

I'll see that and raise grandparent to merdivorous blasphemite. "I rediscovered ..., and was surpised ..." Comma within a compound predicate? For shame, sir.

Re:PHP's Comeupance

[Anonymous Coward]

Comma within a compound predicate? For shame, sir.

That's an ancient (now deprecated) device for rhetorical effect.

Re:PHP's Comeupance

[mike.newton]

I learned it last year after watching Eternal Sunshine of the Spotless Mind. Brilliant movie. I shan't make pretenses of being a 19th century intellectual, so likely won't be modded up in this thread.

Re:PHP's Comeupance

[Anonymous Coward]

God damn that is some funny shit!!!

Re:PHP's Comeupance

[stonecypher]

Uh.

Of course a constant can't be a variable. In a language with no concept of volatility, the two are diametrically opposed.

As far as their not being objects or arrays, well, duh: constants are scalars. What PHP calls a class constant, c/c++ would call a compile-time literal. These are not things whose values cannot change. These are things which are known to be firm from the second the script is started up. You can't have array literals in most languages, and UDT literals almost don't make sense.

As far as they have to be string constants, bologna. They can be integers, floats, characters, or in fact any scalar type PHP supports.

Now, as far as type hinting only working on classes. Of course it only works on classes - you don't need type hinting for base types, because it's a magically typed language. No, that's not a bug. It's also not a feature. It's common sense.

Plz2comment on langauges you understand, kthx. +5 informative my ass.

Re:PHP's Comeupance

[stonecypher]

Well as long as you bring up grammar:

1. Sir is not capitalized. This miscreant tendency is American ignorance of the proper title Sir as given during knighthood by royalty. You may call Sir Edmund Hillary with the capitalized Sir. Given your obvious deep familiarity with the 19th century, perhaps I should also refer to Sir Mick Jagger. Some random person on Slashdot most likely has not attained such a title.
2. "is it informative" - you've got a typo, and informative is not a proper noun, even when cataloguing moderator points.
3. As an aside, please don't refer to something as informative unless you know privately. As I display in another reply, in fact the parent post to which you refer is bunk.
4. To debase is to make immoral, not to water down with ill speech.
5. To draft is to draw, sketch, or make a crude preliminary version of something. Whereas speech can be drafted, unless this is a particularly subtle insult - which your usage of language suggests that it is in fact not - then what you are looking at is a final copy, not a draft. Even email programs get this one correct.
6. Queen's English is posessive.
7. It's called the King's English. The Queen's English is a reference to specifically Queen Victoria, and was a temporary tipping of the hat to the first gynarch generally recognized by Britons. We do not continue to tip our hat to her.
8. It's hard to tell whether a reference to proper English, immediately followed by the appalling "Internetland," is intentionally tongue in cheek. As a rule of thumb, if people aren't sure whether you're joking, then your joke has failed.
9. To obtain is to take something which someone else had had previously. Given that frist psot!!1!eleven is not something which can be stolen away from someone else, to use obtain in this fashion is ill.
10. To covet is to desire or lust for something sexually; it comes through Old High French's "covitiere," thence from Latin's "cupidere," the cherub of Eros. If you covet first post, seek help.
11. Furthermore appropriately follows further. You've gone from first to third. Further, it makes you look stupid. Furthermore, it should be stated in the fashion I've just given.
12. Epistles are letters sent by clergy as regards scriptural canon. Even were you the Pope of Grammar, which you are not, this would be incorrect.
13. "So to speak" is the verbal equivalent of the better-recognized editorial "[sic]." It indicates specifically that you are repeating what someone else has said verbatim, despite being aware of language errors of some or another form. Hence, if I were to say that you had said "pole position of posters, so to speak," so to speak, I would refer to your inane use of the phrase "so to speak."
14. Congratulation is singular. To refer to congratulations is to refer to a group of such statements, or to such a statement given to a group as a set of individual congratulatory statements. That said, I do applaud your use of the contextually accurate accolade, and hereby give you congratulation therefore.
15. A toast, in the context of wine, is a speech. You cannot drink a speech.
16. One drinks for you, not to you.
17. It is common misconception that the word concieve may be used to refer to impregnation. To concieve a child is to begin to attempt impregnation. Many people who concieve a child never have children, and in most cases time is taken between conception and impregnation.
18. Correspondance is the third or latter piece of a private exchange between a small group. This is an edict, if anything.
19. You wish that something should, not that it shall. Shall is affirmative. The sun shall continue to rise. Something which is indefinate should continue. Murder should remain illegal. Wishing for something definate is silly.
20. The idea that a correspondance would be eternal is a bit chee

Re:PHP's Comeupance

[(1 -sqrt(5))*(2**-1)]

Of course a constant can't be a variable.

The variable-value is assigned to an immutable constant by copying memory; Java does it all the time.

As far as their not being objects or arrays, well, duh: constants are scalars.

That's begging the question, I'm afraid; see Java.

[Y]ou don't need type hinting for base types, because it's a magically typed language.

Then why introduce type-hinting this late in the game (PHP 5)? Zend violated their self-imposed directive of loose types, and did a half-ass job at that.

Re:PHP's Comeupance

[Anonymous Coward]

PWND

Re:PHP's Comeupance

[stonecypher]

Of course a constant can't be a variable.

The variable-value is assigned to an immutable constant by copying memory; Java does it all the time.

Way to miss the point. I didn't say that a constant couldn't be created from the value held in a variable. That is in fact quite easy, and the syntax is essentially the same as it is in C++. What you were complaining about was that constants couldn't be variables. Constant means it doesn't change. Variable means it changes. Again, in a language without volatility, that doesn't make sense.

It has nothing to do with the way in which the value of the constant is established, and if that's what you originally meant, you should have actually said that, so that I could tell you how that's done instead. Because, y'see, the thing you've changed what you wanted into is also quite possible.

As far as their not being objects or arrays, well, duh: constants are scalars.

That's begging the question, I'm afraid; see Java.

That most certainly is not begging the question. There's a huge difference between the set (!{objects,arrays}) and the set ({string constants}). What you said originally was that they had to be string constants because they couldn't be objects or arrays. The reason I said scalars was so that you'd go "oh right, they can be integers or floats or characters" or all those other things you conveniently removed from the quote.

By the way, begging the question is a fallacy, which is an argument used to support a premise. I'm not arguing. I'm stating. If you don't believe me, you can read the manual, which is both normative and definitive. There is no question of whether or not something is right. If the manual agrees with you you are correct; if it does not, you are not. Even if I was wrong, there is no option for fallacy here, therefore it cannot by definition be petitio principii.

[Y]ou don't need type hinting for base types, because it's a magically typed language.

Then why introduce type-hinting this late in the game (PHP 5)? Zend violated their self-imposed directive of loose types, and did a half-ass job at that.

Because it's a useful tool. The "self imposed directive" you claim doesn't actually exist. Once again, if you'd bother to read the manual, you would know that magical types only apply to base types. Ho hum, maybe that's why you don't need type hinting for base types. Coincidentally, that's also why you do need type hinting for UDTs. Maybe that's why they made it - so that you could enforce type contstraints where they were nessecary.

Amusingly, this actually is begging the question, though it's better classified as a straw man. Y'see, you've assumed that the reason it's bad that type hinting is going on is that magic typing obviates it. You've also assumed that the reason that type hinting is broken is that it doesn't occur in base types, where it's obviated. Finally, you've decided that they made some broad proclamation which in fact they did not, by implementing a single language feature for UDTs, and that they've somehow broken language consistency by introducing a parallel tool for when the first tool didn't well suit UDTs.

You want to know why they don't magically type UDTs? Because it's not realistic in an inherited language. If you don't see why, then you don't understand inheritance well enough to criticize the decision. There are many cases in which there would be no way for the compiler to magically determine which of several possible bases you actually wanted. Therefore, you need a way to specify it manually.

Please actually read the PHP manual before replying. All of these things are well documented, and you wouldn't be being abrasive if you'd actually read it. Hell, you might even understand the langauge choices they made, which would probably be good, considering how much newer and more limited domain PHP is than Java, and how it's still more popular. There's a reason: it's a language which works well. Sure, it's got some cruft, but you happen to be pointing at one of its best features when you're screaming "this is broken."

Hush, dear. You don't understand.

Re:PHP's Comeupance

[Anonymous Coward]

To pull this off properly you have to avoid errors such as your last sentence where you use a question mark at the end of a non-interrogative.

Re:PHP's Comeupance

[rayray14]

You read my mind, good sir!

Re:PHP's Comeupance

[user24]

it's used in legal fields to denote a loophole in the law. I think this is the sense intended above.

PHP 4 V. 5

[wesw02]

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.

Please Note:

[Anonymous Coward]

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

Re:PHP 4 V. 5

[karvind]

Google is your best friend.

From php.net

If you're going to be this generic...

[xxxJonBoyxxx]

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

[cnerd2025]

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

[sammy baby]

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.

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

[Anonymous Coward]

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.

Or you could hope that someone develops a database based on RELATIONAL THEORY and includes UPDATEABLE VIEWS so that schema migration becomes trivial.

No idea what I'm talking about? Of course, because SQL CAN'T ALWAYS DO IT! Even though the theory was developed 30+ years ago.

I mean: you add/change columns in your DB.. your OLD code sees the old schema, and your NEW code sees the new schema, and you slowly replace all uses of the old schema with the new one, then you delete the old schema, and your data remains untouched the whole time.

Kinda like, I dunno, REFACTORING?

Still waiting for somebody to dust off those theory books and implement!

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

[aled]

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

Can you give some pointer as how to do that as well? oh wait, I see it...

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

[HermDog]

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.

Jeff, is that you?
I just finished my first 10 months in my new job and already I've discovered that we have TWO of these tables. They are in different databases, otherwise we'd only need the one. (I crack me up. I wrote "need.") One isn't quite so clearly insane as the other, but that's only because it is so cleverly disguised.

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

[sammy baby]

Sweet Jesus, that's funny. (and no, I'm not Jeff. I'm Sammy. Hi!)

Not two hours after I posted my thing here, I hopped onto The Daily WTF, and wouldn't you know that this was the WTF of the day? I'm not sure which is worse, a serialized object for all the important data, or an XML document...

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

[mixmasterjake]

Actually you could make this class totally generic by having it query the DB for all the field information. That could even include validation to make sure the input is the right type, length, etc. All the info you need for that is in the DB. The problem is that, unless you're just writing a generic DB table editor app, you generally need unique methods for each table/object.

If you find this kind of thing interesting, it's probably worth checking out some persistance layers like hibernate or (for PHP) Propel

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

[Anonymous Coward]

> your OLD code sees the old schema, and your NEW code sees the new schema

I think you need to reevaluate your distribution model.

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

[Anonymous Coward]

Sounds like what is really needed is an implementation of "Dynamic Relational":

http://www.c2.com/cgi/wiki?DynamicRelational

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

[cerberusss]

Have you thought about patenting this great concept?

Experiences

[truthsearch]

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

[Anonymous Coward]

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

[JabberWokky]

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

[T-Ranger]

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

[Tenareth]

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

[killjoe]

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.

Re:Experiences

[shmlco]

"At that point function names could be standardized..."

YES!!!! Not just names, but parameter order as well. Most the functions work one way, but there are just enough that reverse target parameters that you can never be quite sure you got it right.

PHP: Over a billion functions served... and counting.

Re:Experiences

[masklinn]

technically there is nothing python can do that php can't

Turing-completeness also states that, technically, there is nothing Python can do that Whitespace can't. That doesn't mean you have to use Whitespace..

Re:Experiences

[1110110001]

There's a type hint for arrays. The other types need no explicit type hint as PHP is meant for web development and both HTTP and HTML only support strings. It would be bad to have a function call fail because your string of digits is not casted to an int. Of course you still can, but than there's still no use for a type hint in that case.

Same goes for overloading. If you need to cast your parameters you could also write method_for_number and use a string of digits or an int or a float.

Re:Experiences

[1110110001]

A response in the Web enviroment shouldn't take longer than ~3 seconds and most of that is just transmitting data. So your script runs for less than a second - and you want thread for that short time? The only thing that needs to be async in PHP is IO and you can use http://pecl.php.net/package/event for that.

Maybe you're used to programm in a specific way. But PHP won't be the language for that. I don't unterstand you argument for scaling, but maybe that's because of you not unterstanding scaling.

Re:Experiences

[Zwets]

technically, there is nothing Python can do that Whitespace can't. That doesn't mean you have to use Whitespace..

trueineverusewhitespaceanditneverdidmeanyharm

(yes, I know about the programming language Whitespace. And, for good measure, let's throw in Brainfuck and its Pratchettesque dialect Oook)

Re:Experiences

[Mr. Slippery]

Most the functions work one way, but there are just enough that reverse target parameters that you can never be quite sure you got it right.

You can look it up, you know. Very easy way to be sure. I usually have a browser tab open to TFM. Quite handy.

PHP inherits functions from a rich variety of sources. Those sources often have differing parameter orders. No big deal. (But then I'm a C guy from back in the day, got used to having to look up things like memcpy vs bcopy.)

PHP

[Jeian]

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

Re:PHP

[drpimp]

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

[Anonymous Coward]

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

[Anonymous Coward]

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

Re:PHP

[Ford Prefect]

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

[deep44]

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

Re:PHP

[A beautiful mind]

How true.

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

Re:PHP

[Unski]

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

[eargang]

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

Re:PHP

[iBod]

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]

Re:PHP

[nbritton]

@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

Re:PHP

[WilliamSChips]

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

[Unski]

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

[woolio]

What is it with this tedious Perl clique on Slashdot?

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

Re:PHP

[Anonymous Coward]

this is funny you fuckfaces

Re:PHP

[masklinn]

Really, no.

Re:PHP

[larry bagina]

PHP actually started as a front-end to perl... so yes, it did reinvent it.

Re:PHP

[DavidTC]

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.

They are always upset when anyone chooses any other language for any purpose, because, in any touted feature of any language, you can do exactly the same thing almost exactly the same way in Perl, but better. That is not sarcasm, I am not being ironic, it is flatly true. Often you can literally cut-and-paste the code.

Other languages have an easy way to do something, and a correct way to do something, and a stupid way to do something you get from newbies. You can usually figure out what any line talking about in thirty seconds once you grasp the syntax. (Which, admittedly, can take a bit of time, like with COBOL and Lisp, for examples of languages with semi-odd syntaxes that are not in any other way alike.)

Perl has all those ways, and one hundred others. This is not an exaggeration. You can write BASIC in Perl, you can write PHP in Perl, you can write C in Perl, you can write Lisp in Perl, you can write C++ in Perl.

You sit two programmers of a medium skill level and have them write asm, and they will write identical code. You have them write C, and they will write near-identical code. You have them write PHP, and they will be roughly the same. You have them write Perl, and sometimes one of them will come up with at least one line that the other doesn't immediately recognize, because one of them basically writes PHP in Perl, and the other basically writes C++ in Perl.

This isn't limited to Perl. Programmers often write C in C++, or PHP 4 in PHP 5. When languages get new, better ways to do something, you end up with an 'old style' and a 'new style' and people can upgrade the language itself without upgrading the style they write in. Other people work on their codebase and put in 'new' stuff, and the old guys are baffled.

Perl is merely the only language that has ever deliberately done this. Perl is like being able to write in any programming style you want, at any time, using a semi-consistent syntax, along with features that no other language likes, like $_. Perl fanatics are under the mistaken impression this is somehow a feature, as opposed to making it fucking impossible to ever read any Perl code unless it happens to be written in the style you know.

Re:PHP

[Anonymous Coward]

You have them write Perl, and sometimes one of them will come up with at least one line that the other doesn't immediately recognize

And. you. say. this. like. it's. a. good. thing.

Re:PHP

[CTachyon]

I'm sorry it doesn't click for you, but from my perspective, Perl rocks. It's got just about the perfect blend of C syntax (which, as ugly as it is, has proven surprisingly readable -- witness new languages like Java, C#, and PHP still borrowing from it) with LISP power. Now that I've used closures and higher-order functions in serious code, I can never go back. Just about the only LISP things it's still missing are macros and continuations, and both of those are coming in Perl 6. (Oh, and a real garbage collector. I like Perl 5 a lot, but refcounting sucks.)

PHP 5, unfortunately, still doesn't support higher-order programming. Now, I have to hand it to them, it's a much nicer language core than PHP 4 was, but it still looks like Perl on training wheels to me. I might look at it again when array_map() takes a closure instead of a string, but not until then.

Re:PHP 4 V. 5

[drpimp]

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

Re:PHP 4 V. 5

[lbft]

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

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 if you're familiar with PHP 4.

Re:A bit off topic...

[B3ryllium]

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

OOP

[onion2k]

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

[truthsearch]

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

[Tablizer]

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

[Fahrenheit 450]

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.

Re:OOP

[IgnoramusMaximus]

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

[ctr2sprt]

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

[yintercept]

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

[IgnoramusMaximus]

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

[Tablizer]

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

[Tablizer]

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

[Mateo_LeFou]

Great post. Here I thought I was the only guy who doesn't necessarily want to get married to a "framework" as soon as possible. Yes, Rails can do CRUD more quickly and "better" than P5. But about 5% of my clients could be satisfied by basic, even customized CRUD. Two months into every project, you have to ditch the framework or refactor damn near every class in it.

Re:OOP

[stedo]

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.

I find your lack of lather disturbing...

Re:OOP

[DavidTC]

Why the hell has this been posted for almost three hours and only scored a 3?

You are exactly right about OOP. It's great when you are writing code for yourself. It's even okay in an large project with multiple people. It is craptacular when trying to extend preexisting objects that you can't modify.

And it is incredibly dumb in an environment like PHP. You know, PHP...the language that executes for 20 seconds at a time, and then starts over?

I'm all for things like directory listings and mysql results to be returned in objects. You're just looping over the damn things, and it doesn't really matter how you do it. It's the making your own objects that last for five seconds, and exist entirely within your own code, that seems a bit dodgy to me.

Re:OOP

[TLLOTS]

I can agree with your comments to an extent with respect to OOP being touted as a magic bullet and being pushed for uses in places where it doesn't actually suit. However regarding your comments about the fundamental aspects of OOP such as reusability and encapsulation, I have to respectfully disagree.

OOP isn't a magic bullet, it won't make any code magically better somehow. If you're a bad programmer who writes crap, then all OOP allows you to do is write more complicated crap. However, OOP can be a fantastic tool when used properly. Much like XML for example, many people get caught up in the hype and only learn how to use it, not when to use it, leading to many people trying to squeeze it into places where it just doesn't fit.

Re:OOP

[IgnoramusMaximus]

OOP isn't a magic bullet, it won't make any code magically better somehow. If you're a bad programmer who writes crap, then all OOP allows you to do is write more complicated crap. However, OOP can be a fantastic tool when used properly.

Unfortunately, this applies to just about any other paradigm. A good assembly coder will write a massive business application in it (it has been done more then once) and he will be able to maintain it quite well too. This does not however mean that assembly lanugage coding is therefore somehow superior to all other paradigms out there. OOP is merely a view, a perspective on things. Just like a doctor would examine a patient's leg with his eyeballs, feel it with his hands, use plain X-Ray machine, CT scanner, MRI or maybe take a biopsy sample: all being different perspectives of the same object, each suited better to a different task at hand. So is OOP, which fits best particular kinds of use, that of simulating real-life objects or objects closely corresponding to them (certain UI elements etc). But it has little to no advantage over other approaches elsewhere. It is merely practically equivalent to them. Note that all programming paradigms are all equivalent to each other, mathematically. Everything that can be expressed in OOP can be expressed in functional programming or even logical predicates (ala Prolog). All of these end up translated into machine code anyway or else the CPU would be helpless in executing them.

Much like XML for example, many people get caught up in the hype and only learn how to use it, not when to use it, leading to many people trying to squeeze it into places where it just doesn't fit.

Which is my whole point. XML is also merely a perspective on data. And like OOP it has its uses and their anathemas as well. And like OOP it is being overused severely because the marketing hype seems to have defated reason, and abysmal inexperience of some young programmers leads to fashion and "cool" trends ruling supreme where one would think detached, objective analysis should have.

Re:OOP

[TLLOTS]

I'd agree with that, my only issue with your previous comment was that you seemed to be saying that there were very few good applications for OOP which I disagree with, at least with respect to my own admittedly limited experience. If I misunderstood you then you have my apologies.

Re:OOP

[yintercept]

It seems to me that the main drive for OOP is that teachers want something compelling to say in the classroom. The lecture where you way that OOP transcended procedural languages, then patterns transcended OOP is very compelling.

Unfortunately, the compelling classroom lecture leads people to the assumption that code written using classes is superior to code written using procedures.

In the scripting world, I don't think classes are always the best option. A script, by its nature, is something designed to be executed quickly in a single action. The whole idea of an object is that the object controls the data from start to finish. In a scripting language, like PHP, each script is short lived. The classes in a standard PHP implementation get created and destroyed with each execution of the script. The object isn't conrolling the data, the database is controlling the data.

A PHP object is simply a holder of data during a short execution of one method of a script. The fact that I have to reload the object with each execution of the script tells me that I am really not living in an object world.

Take something simply like a Session object. Think about this for a moment. Your /. session starts when you write slashdot.com in the address bar. You read a few messages, and drop a few pithy comments. Your session ends when you go off to do something else or close your browser. If I were thinking of this in object terms, the constructor should be accessed when you first write slashdot.com. The destructor should fire when you close your brower.

When I look at the PHP code for a user forum like /., I might see that each execution of the script includes the line "$session = new Session()".

In my object model, the session begins only once. The fact that I am initializing the Session object multiple times during a session tells me I am not in Object heaven. The data that controls the session is living in a cookie or living in a database. The object that I create with my Session class is just an illusion. It is simply an objectlike structure.

Accepting that I am not in an object environment, I next find myself wondering if using the class structure is really the best way to implement objectlike programmingIt seems to me that the main drive for OOP is that teachers want something compelling to say in the classroom. Presenting a model where OOP transcends procedural languages, then patterns transcends OOP makes for a compelling class.

Unfortunately, the compelling classroom lecture leads people to the assumption that something written using classes is better than something written using procedures.

In the scripting world, I don't think classes are always the best option. The whole idea of an object is that the object controls the data from start to finish. In a scripting language like PHP, each script is short lived. The classes in a standard PHP implementation get created and destroyed with each execution of the script. The object isn't conrolling the data, the database is controlling the data.

A PHP object is simply a holder of data during a short execution of one method of a script. The fact that I have to reload the object with each execution of the script tells me that I am really not living in an object world.

Take something simply like a Session object. Think about this for a moment. Your /. session starts when you write slashdot.com in the address bar. You read a few messages, and drop a few pithy comments. Your session ends when you go off to do something else or close your browser. If I were thinking of this in object terms, I might say an object starts when you access slashdot.com, and finishes when you close your browser.

When I look at the PHP code for a user forum like /., I might see that each execution of the script includes the line "$session = new Session()".

In my object model, the session begins only once. The fact that I am initial

Re:OOP

[IgnoramusMaximus]

I'd agree with that, my only issue with your previous comment was that you seemed to be saying that there were very few good applications for OOP which I disagree with, at least with respect to my own admittedly limited experience.

Your impression comes from this misunderstanding: what I said in effect is that there are indeed very few good uses for OOP when compared to the promises made by its proponents. So, yes I said something of the sort, but it was not an absolute statement by any means. OOP is not qualitatively different from all the other paradigms past. Just different. That means that while it is not universally inferior, it is also not universally superior to all the others. But that is not how it was sold to us mere mortals, never you mind pointy-haired bosses. The hype, although still very strong now, would, back then, have you believe that a state of Nirvana was upon us and that every hamster will be able to produce self-maintaining Fortune 500 CRM application by judicious and sporadic farting thanks to the miracles of OOP.

Re:OOP

[Slashcrunch]

What is wrong with _generating_ real files containing classes and definitiions from your DB schema?
Handle all the basic crud stuff there. Its not that difficult, although the example given in the article was definitely on the fun side of things. Generating classes based on schema isn't hard at all, I've been doing this in PHP for quite some time.

Once you've generated your DB layer, create a 'business' layer. Classes or code in this layer may extend or use the DB layer, but essentially the Business rules go here. You never modify the DB layer by hand knowing full well that it will be overwritten at some point by the generator. There are no runtime issue with intropspection of classes, code complete Just Works, and you have real classes to look at when you find a bug. If a bug is found with your generated DB classes you fix the generator and run it again. Its just so simple and there is no CRUD monkey work to be done :)

I'm all for eleagnt and 'classy' (get it?!) solutions to problems, but what about "Keep It Simple, Stupid" ?

Re:OOP

[Tablizer]

I generally agree, but:

I've realized that I've pretty much regressed back to traditional database programming that I find myself compelled to use a traditional approach to database design.

RDBMS are actually newer than OOP and both grew up about the same time. Thus, saying that RDBMS is "legecy" compared to OO is misleading.

(By the way, I think you accidentally pasted some of the same text twice. No biggie.)

Re:OOP

[Decaff]

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

Awesome! I remember exactly the same detailed and well-argued articles being posted against the use of procedural code in the 70s. Procedural code was 'just a paradigm', and pointless as it could always be implemented with the right combination of 'GOTO's.

Re:OOP

[Foofoobar]

Well I use PHP 4 and PHP5 to build MVC frameworks and except for some MINOR issues, I can do just about everything with objects. The only thing that I really have to have procedural is the index.php page which I consider as my MAIN class (as it performs the same function in an MVC framework as I use it as my controller).

I think the main problem is that PHP is mainly a web scripting language and some people try to apply their knowledge in application development which doesn't quite translate. For web dev, you have to think slightly different. You can do nearly everything object oriented in PHP by passing objects, instantiating classes in other classes, etc.

Just because you haven't done it does not mean it can't be done. When in doubt, ask on a forum or seek professional counsel.

Re:OOP

[StormReaver]

The point being made is that OOP principles were being used in procedural programming long before OOP principles were formalized. OOP is a formalization and extension of certain long standing techniques that proved to be productive, many of which you almost certainly use even in languages that do not specifically define them.

OOP languages make those techniques easier. The first 14 or so years of my programming life were as a procedural programmer. The last 7 or so were as an OOP programmer in a variety of OOP languages. It's highly painful for me to have to use non-OOP languages, as there are just too many dramatic efficiency gains provided by OOP programming.

OOP is not a fad that is going away. The productivity gains are too real and too substantial. OOP is also not going to remain static, but will rather evolve. No amount of attempted and/or nonsensical humor is going to change that.

Re:OOP

[Anonymous Coward]

> "Easier reuse" - This is utter nonsense. Show me an example.

CPAN.

Yer just a paragon of engineering talent, aren't you? Show me an example of your fantabulous code.

Re:OOP

[yintercept]

I started writing everything in objects. My idea at the time was to prototype in PHP, then rewrite in Java. After a lot of system testing, I found that I was getting better performance by using straight procedures.

It is the nature of logic that you can do everything either with classes or with procedures. The difference between the OOP and procedural programming gets down to questions of speed, supportability and style. The first thing I realized was that rendering a full object model for a standard web application was a little bit too slow (because you end up having to load the full model with each action). Realizing that I was not running a full object model, the next question was whether or not I really gained anything with the overhead of rending everything using a class structure. I decided that it was not. I love the ego points I score writing in an object like style. But, it really comes down to speed and supportability. My experience is that procedural design has a lower profile that you want in a scripting environment. That low profile matters more than my self image.

Re:OOP

[IgnoramusMaximus]

Awesome! I remember exactly the same detailed and well-argued articles being posted against the use of procedural code in the 70s. Procedural code was 'just a paradigm', and pointless as it could always be implemented with the right combination of 'GOTO's

The joke is of course on you. Because it can be indeed so implemented. The assembly language perspective of a program has of course many dis-advantages but it also has great advantages, if deployed in its optimal application. All of these paradigms are equivalent, on the fundamental level, mathematically. As someone has posted on this very thread, the utility of a different paradigm depends on the domain of its application and also on the mode of thinking of the programmer. That is why some can crank out superb applications in C, some others swear by LISP, while at the same time some others need Java to be able to function. Paradigms and languages are tools. Nothing more. They are not omni-potent, nor universally superior to one another.

Re:OOP

[IgnoramusMaximus]

OOP is not a fad that is going away.

It is a fad to the extent of its ludicrous over-emphasis and present hype. The same thing has happened with procedural programming before, and functional one at one time too. All were, just like OOP in your view, providing "just too many dramatic efficiency gains" to consider anything "older and yucky" for their respective adherents. It was to be recursive functions operating on hardware-assisted CONSes all the way to the glorious future. So OOP will "go away" in the sense of becoming just another tired old paradigm, on par with all the previous ones and all the sheep will move onto some new sparkly, shiny thing of the future. And the cycle will repeat itself. There of course will be devoted adherents of it, swearing up and down by their Javas and what not, right next to the LISP, Pascal and Transputer (remember that revolution which was to change everything?) folks, while the masses will be busy screwing around with their "Quantum Spin Computing Exrtapolation" paradigm, or whatever will that new thing be.

Re:OOP

[IgnoramusMaximus]

The point being made is that OOP principles were being used in procedural programming long before OOP principles were formalized. OOP is a formalization and extension of certain long standing techniques that proved to be productive, many of which you almost certainly use even in languages that do not specifically define the

Oh and one more thing, this same reasoning can be applied to any of the other paradigms. Some LISP hack will swear up and down that the OOP folks are merely revisiting functional techniques which were already used by the assembly language programmers in 1961 and that you have simply renamed his beloved lambdas into "methods" and his dynamic function dictionaries into "classes". He will even prove it to you by putting it all in LISP lingo in two million different ways, an example of which is the CLOS system. And so on and so forth. A never ending game of "my paradigm is bigger then your paradigm!". Thanks for playing, but there are no winners possible in this retarded game.

Re:OOP

[Foofoobar]

Well it depends. You can be overly verbose and bloated with your objects (including functions that you won't use) and you can be highly redundant and bloated with procedural code.

Both have their use (even Java has procedural code in it's MAIN class and in other places). I generally use objects when what I am doing is highly redundant (I'm calling in more than once). To ignore this and do it procedural means you get the privilege of maintaining the same codebase in several locations.

In other cases, sometimes objects actually over complicate the issue and add more code than is needed for the task at hand.

Good coding is all about knowing when to use the right tool and how to apply it.

Re:OOP

[Decaff]

The joke is of course on you. Because it can be indeed so implemented.

Where did I say it couldn't?

Paradigms and languages are tools. Nothing more. They are not omni-potent, nor universally superior to one another.

Yes they are. For certain use cases different paradigms are definitely superior to one another. To imply that large libraries could be implemented without procedural code and just with GOTOs is plain silly.

Re:OOP

[IgnoramusMaximus]

For certain use cases different paradigms are definitely superior to one another. To imply that large libraries could be implemented without procedural code and just with GOTOs is plain silly.

I am not sure what sort of computer you would be referring to, for as far as I know, every Turing-style machine since sometime around ENIAC had also an equivalemnt of BASIC's GOSUBs. All assembly languages I have ever seen for these Turing-tape-style machines, which we use nearly exclusively, have CALLs in addition to JMPs (or BRANCHs etc). And that was loooong before the term "procedural programming" entered the scene. But even if they don't, the action can be simulated by placing an address in an area indexed by a memory or register stored pointer (label it the "call address") and then jumping to a routine labelled "call" which will place the instruction pointer in another area, indexed by another register (call it the "return stack pointer") increment it and JMP to the specified address, another piece of code labeled "return" will do the reverse if JMPed to. You are wrong, again.

Re:OOP

[Decaff]

You are wrong, again.

You are talking off topic, again.

This is about how a high level developer should code, not how things are actually implemented.... of course,if you want to talk about electron flows through transistor gates.....

Re:OOP

[IgnoramusMaximus]

You are talking off topic, again ... This is about how a high level developer should code...

No, this is about a supremacy of one paradigm over another. High level? There were complex computer systems around which were not only programmed exclusively in assembly, but the very user interaction with all of their programming consisted of numeric entry, separated with 4 keys: 'program', 'verb', 'noun' and 'enter'. As in Program 27 Enter, Verb 2 Enter, Noun 3 Enter, +00231 Enter, etc. One such computer was called the AGC and was responsible for a trifle thing like landing the man on the Moon. High level? A priest of fuctional programming will be making exactly the same arguments as you are making, something about "high level of functional abstraction". A FORTH coder will be right there with you arguing about how his word dictionary is indeed "high level" in all respects. And so on. This has nothing whatsoever to do with how things are implemented (except to demonstrate the equivalence of all paradigms to each other on a fundamental level). The supremacy of your favourite paradigm is all in your head and it is not a universal nor an objective assesment. Some things are merely easier for some people in one paradigm at the expense of other things.

Re:OOP

[Tablizer]

It's highly painful for me to have to use non-OOP languages, as there are just too many dramatic efficiency gains provided by OOP programming.

I assume you mean developer efficiency and not CPU speed. If so, there has never been a documented example made public outside of systems software. Perhaps your particular brain is more comfortable with OO, but it has not been shown in any externally demonstratable way. In short, a subjective preference. It does not fix or improve anything analyzable. It has as much evidence for it as Intelligent Design, to be frank.

Re:OOP

[Tablizer]

Yes they are. For certain use cases different paradigms are definitely superior to one another. To imply that large libraries could be implemented without procedural code and just with GOTOs is plain silly.

It is called "Turing Equivalency". You are wrong on this one. As far is developer convenience, though, that is a different matter.

Goto's were inconsistence from developer-to-developer and lacked visual cues that indented blocks give. These same lessons don't apply to OOP that I can see.

Re:OOP

[Decaff]

It is called "Turing Equivalency". You are wrong on this one. As far is developer convenience, though, that is a different matter.

Sorry, but I am not. How can I be "wrong" when I was talking about develop convenience? Everyone knows that raising Turning equivalency is a last-ditch and pointless justification.

Goto's were inconsistence from developer-to-developer and lacked visual cues that indented blocks give. These same lessons don't apply to OOP that I can see.

That you can see: that is the key. Just because you can't, doesn't mean that others can't.

Back in the 70s many of us actually used indentation to indicate the logic behind gotos!

Re:OOP

[Tablizer]

How can I be "wrong" when I was talking about develop convenience?

I apologize, I misunderstood you, thinking it was an absolute implementation claim.

That you can see: that is the key. Just because you can't, doesn't mean that others can't.

Well, nobody has found a way to demonstrate it the way we have found with Goto's. "It makes me comfortable" is not sufficient, especially since there are competing comfort claims. If one cannot find a way to demonstrate superiority extnerally, then claims of subjective preference cannot be dismissed.

Re:OOP

[Tablizer]

To ignore this and do it procedural means you get the privilege of maintaining the same codebase in several locations.

Please show me specific code where procedural *must* duplicate stuff.

Re:OOP

[Dracolytch]

Thank god, I'm not alone.

Praise be.

~D

Hosting services stuck on PHP4

[cknudsen]

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
RSS:
http://www.devpointer.net/browse.php?l=p&t1=1&fmt= rss1

Re:Hosting services stuck on PHP4

[Slushie31]

Check out Telana. 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

[jZnat]

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

Re:Hosting services stuck on PHP4

[Slushie31]

I believe his determination of "stability" (which you will notice I, too, enclosed in quotes originally), is whether or not the new release will break any old code. If it will and it is non-essential, he passes on it, otherwise he'll notify everyone that there'll be an update in xx days that will break xyz.

Re:Hosting services stuck on PHP4

[cknudsen]

It's good to know that at least some of the hosting services provide PHP5. Mine offers PHP5, but only as a CGI. The rate at which open source apps adopt PHP5 is somewhat dependent on these hosting services.

Personally, I don't want to have to tell potential users that they will need to switch hosting services to use WebCalendar. I would think about it if there were a real compelling reason to go with PHP5. This particular article doesn't suggest to me that there is. Better exceptions, interfaces and other features borrowed from Java are also nice, but I can still program around those limitations with PHP4.

Re:Hosting services stuck on PHP4

[iamlucky13]

It sounds to me like his concern is not finding a host for himself, but for other people using his applications. He may want to add some of PHP 5's functionallity to his app in order to add new features or improve performance, but his customers can't use it until their host upgrades, and it seems most hosts are still running PHP 4.

BTW, if ya'll will forgive a minor digression: it's about time microtime() was able to return a float value! I never understood why it comes back as a string, and it took me quite a bit of fooling before someone finally pointed out in the user notes:
$float_microtime = array_sum(explode(" ",microtime()));

Re:Hosting services stuck on PHP4

[jZnat]

Technically, I'd consider old code that breaks under new releases to be unstable. PHP isn't Java; it isn't hard to maintain compatibility (as the standard for that doesn't change too often)...

Re:Hosting services stuck on PHP4

[Ramses0]

Good web-hosts will let you choose between various versions on a per-domain basis. Dreamhost also gives you access to some bits of .htaccess files which I assume you could link *.php4 to the php4 cgi and vice versa for *.php5. Yeah, the cut-rate shared hosters probably don't have the same level of management capabilities, but there are some out there that will let you do some really useful things (ie: ssh access, gcc, svn, cvs, php, ruby, python, mysql, etc, etc, etc). I guess one of their big gaps is with Postgres, I'd be interested if they had some of those management utilities available, but like it or not, most people and projects are MySQL specific.

--Robert

Re:Hosting services stuck on PHP4

[Paradise Pete]

FYI.... PHP developer articles updated daily:

Thanks for the link! Very useful for all my webbin' needs.

Re:Hosting services stuck on PHP4

[Anonymous Coward]

You don't need thousands of PHP5 servers, you only need one.

Re:Hosting services stuck on PHP4

[cerberusss]

Have you thought about using a complete virtual machine instead of a simple webhosting account? Check out any of the following companies: Redwood Virtual, WestHost, eApps, UnixShell, PigsCanFly, etc.

You have root access to an UML instance with your own IP address. You can install everything you want. Everything? Everything.

always remember

[Anonymous Coward]

Linux is NOT backwards compatible.

Not The Best Choice For Maintainable Code

[tres]

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) 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

[prockcore]

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

[T-Ranger]

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

[lewp]

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.

Re:Not The Best Choice For Maintainable Code

[masklinn]

Please, sir, don't EVER write any ORM.

Re:Not The Best Choice For Maintainable Code

[aevans]

why not: Customer::add("name=Bob", "phone=555-1234") or even: $bob = ORM::Create("customer"); $bob->name("Bob"); $bob->phone("555-1234"); DB::connect("user:pass@dbname/example.com"); DB::insert(ORM::to_sql(& $bob));

Re:Not The Best Choice For Maintainable Code

[DavidTC]

The line of code to compare with the first part is:
insert_customer("Bob","555-1234");

The second part is, however, quite close to the part that would go inside insert_customer() and the Customer constructor, no matter which you used.

Although most sane people will open the database at the start of the PHP script and put the handle in a global variable, not open it each time you want to do a query or insert. And not close it at all, because that doesn't do anything unless you're running out of memory in the middle of a script.

Also, you should put the database name in the query, like 'insert customers.customers ...' in this example, if you're switching between them, instead of using mysql_select_db(). If you're only using one on that connection, you should mysql_select_db() where you opened the connection. Using mysql_select_db() to go back and forth is a good way to screw yourself up.

Infighting between PHP and Perl?

[xxxJonBoyxxx]

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?

[Foofoobar]

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?

[shobadobs]

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?

[Anonymous Coward]

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:Infighting between PHP and Perl?

[shobadobs]

Then clearly your use of Perl was limited to $ in front of variable names, some is-it-a-string-or-is-it-a-number situations, and C-style loops and if statements.

I Prefer The Class Generator

[aaronvegh]

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. It's sweet.

Okay, back to nerding.

Re:PHP 4 V. 5

[Foofoobar]

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.

Kinda Like Ruby

[pkulak]

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

[Yuioup]

"welcome to 1967".

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

Y

Re:I would like to be the first to say...

[MobyTurbo]

"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

[Tablizer]

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.

Re:Alternatives to consider

[HaMMeReD3]

Associative arrays were all php used to offer, and i've been using them as structs to store massive amounts of data in them. Very useful for quick hacking, but not good for scalability, it'll be a mess to try to figure out where anything is later on.

Re:Alternatives to consider

[Tablizer]

Associative arrays were all php used to offer, and i've been using them as structs to store massive amounts of data in them.

It would be nice if PHP offered built-in tables. ColdFusion (CF) does I would note (although buggily). CF even allows one to do SQL on them, although SQL parsing would bulk up any such library. If somebody found a simpler way to do joins, aggregation, filtering, and sorting than such parsing overhead may not be needed.

Crap...

[A beautiful mind]

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.

Re:Crap...

[RancidMilk]

The good thing about "Slashdot - Going dynamic with PHP" is that perhaps with the use of classes, they can reduce the rewriting of articles or at least make it so that they only have to make a "new" one.

Any fool can code Perl...

[iBod]

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

[Unski]

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

Re:Any fool can code Perl...

[panaceaa]

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:Any fool can code Perl...

[masklinn]

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

If it doesn't, then it's not a better language.

To quote Alan Perlis,

A language that doesn't affect the way you think about programming, is not worth knowing.

Re:Any fool can code Perl...

[iBod]

Interesting points Jon.

The availability of proven design patterns certainly enhances any programmer's ability to produce something that works, and is maintainable.

Perhaps that's more important that the actual features (or failings) of the language in the end.

Re:Any fool can code Perl...

[iBod]

What I was saying was that the language is often a 'given' and may not be your preferred language, or the best language for the job in hand.

Neat quote by Perlis but I think it's somewhat out-of-date, or out-of-touch. i.e. if I'm solving a problem then I need to be thinking about the problem - NOT the programming.

Of course, Perlis's whole reason-detre was programming so it's not suprising he though that way.

For me, the programming language is a barrier to getting the problem solved and implementing whatever it is I want to implement.

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

[Anonymous Coward]

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) ??

[jZnat]

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

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

[masklinn]

And types don't even flee the field at runtime (as Java's types do), they're not here to being with.

Interesting, but ...

[isolationism]

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

[Tablizer]

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.

Re:Interesting, but ...

[Anonymous Coward]

Duh, right. Python. Yeah, that's the language
where you have to put a comma at the end of a
one-element tuple e.g. (2,) and where you cannot
take a random array slice like you can in Perl.

Python also implements the raw socket interface
where you have to call socket/bind/listen/accept
instead of just connecting and accept'ing as in
Perl's IO::Socket.

Do people just back bullshit because they have no
powers of discernment or is it because they learn
language A and then recant person X's screed against
language B ... which they know nothing about.

Python is a farce. That's why dice.com has seven
Perl jobs for every one Python job. You can bullshit
morons but you can't bullshit the market.

Questionable code pieces..

[guice]

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

[jZnat]

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.

Re:PHP 4 V. 5

[Anonymous Coward]

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.

DB_DataObject

[schmidt]

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

Re:DB_DataObject

[Anonymous Coward]

http://developers.slashdot.org/comments.pl?sid=177 985&cid=14762368

Re:A bit off topic...

[Anonymous Coward]

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

Too little too late

[zardo]

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.

Re:Too little too late

[Jack9]

There wasn't really much, I yearned for a new, truly OO language

No why's? Like why were you disappointed with 5rc1? Why did you want a new OO language? Why is a language something that makes you sick or happy? I'm betting you're a fanboi who read something disparaging about 5rc1 from a Ruby programmer. Most importantly, Ruby isn't great because of rails. There is evidence that it isn't being adopted BECAUSE of rails. Anecdotes of non-adoption from PHP/Perl/Java/C++ programmers I have read, typically tried using rails.

Re:Too little too late

[zardo]

I actually was checking out python/zope and ruby/rails, I wanted a framework that incorporated ORM into it. I had nothing in PHP5, I actually made my own framework built around Propel ORM, but there was no meta-programming like there is in ruby, which is way cool. When I use PHP I always end up looking up silly functions to do what I want to do in ruby or perl, like the list() function. Everything is a silly function, it's just a bit ridiculous to me, like it is trying to conform to Java programmers and dynamic languages like perl.

I do all my shell scripts in Ruby now, used to do them with Perl, php never made sense for shell programming. By shell script, I mean a replacement for the tired BASH script.

I'm no fanboi, I make my living programming.

Re:Too little too late

[zardo]

Hey I didn't understand the last part of your post at first:

Anecdotes of non-adoption from PHP/Perl/Java/C++ programmers I have read, typically tried using rails.

It looks to me like you aught to give ruby a whirl, if it's getting all these good reactions. Steep learning curve though. I picked up PHP in a day, ruby took much longer to master, unless maybe you're familiar with all the nifty features like iterators, singleton classes, continuations and all that. Pretty much everything an OO programmer could dream up.

Dynamic Methods + Dynamic Tables = Rails?

[Salamanders]

Combining the dynamic getters and setters with the PEAR DB_Table (http://wiki.ciaweb.net/yawiki/index.php?area=DB_T able) 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.

Re:Dynamic Methods + Dynamic Tables = Rails?

[Anonymous Coward]

Yes, RoR can do that.

user = User.new( :name => "Bob", :age => "50" )
user.password = "raptor"
user.save

Will get you something like
INSERT INTO user SET name = 'Bob', age = '50', password = 'raptor'

Etc.

www.rubyonrails.org

Re:Dynamic Methods + Dynamic Tables = Rails?

[masklinn]

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

That's not RoR itself, it's the Ruby ORM (Object-Relational Mapping) called ActiveRecord, which is a subproject of RoR and a separate package (but since RoR depends on it, installing Rails via gems installs ActiveRecord as well).

AR is much sexier than what I see of PEAR DB_Table too, because it really abstracts the database level: you don't insert or update a whateveritis, you save a record (and you don't use hacky arrays and have to retrieve an ID, you just create an object of the good class with the data you need and you're done), you don't select records, you find them (yes, the role is the same, but the semantics of the action are different and the readability is much improved).

And Rails provides a console allowing you to hack around your database in CLI to do tests or whatever you want to.

Re:PHP 4 V. 5

[Heembo]

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

Comment removed

[account_deleted]

Comment removed based on user account deletion

Six more ways to make it more dynamical

[MasterC]

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.

Re:Six more ways to make it more dynamical

[rice_web]

You can!

(1) Object factories are a great way to have extremely dynamic objects. Use something like: $customers = DB_Table::new("customers");

(2) From a MySQL query (and hopefully other DB implementations, too), one can find field information, specifically if a field is the primary key. Thus, if after instantiation of our object, we find a column that is the primary key, allow the object to iterate over it and otherwise iterate in the order specified by a custom ORDER BY statement.

(3) Why not make each row an object with its own __destruct() method? Have each row handle itself.

And the others need no explanation, you pretty much covered everything.

Interesting approach, though I wouldn't use it

[TLLOTS]

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

[jZnat]

Does this have anything to do with OSQL?

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

[TLLOTS]

Since I had to atttempt (unsuccessfully) to find out what OSQL is on wikipedia, I'd have to say no.

I'd be curious to know what it is however, and why it is you wondered if what I discussed in my earlier post was related to it.

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

[jZnat]

It seems to be another SQL abstraction set of classes from a PHP5 framework of sorts. It was the first one I heard today, so I thought that maybe I'd get lucky with a guess.

Ouch

[Anonymous Coward]

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 4 V. 5

[Parham]

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

No Application Scope

[chrisbeach]

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.

Re:PHP 4 V. 5

[jZnat]

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.

PHP: Prostitute Hard Powerful

[Anonymous Coward]

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

[Anonymous Coward]

LISP, bitches!

Re:PHP 4 V. 5

[jZnat]

PHP5 uses MySQLi 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 for a unified database interface (although it is a bit primitive when compared to PEAR DB and other DBIs).

OO and PHP? What's the fuss..

[PietjeJantje]

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.

Re:PHP 4 V. 5

[Anonymous Coward]

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

am I the only one...

[skogs]

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.

Re:LOL (Lisp)

[Tablizer]

LISP, bitches!

I'll give you some advice. If you love Lisp so much, find a better way of selling it. Lisper's have done a horrible job of convincing others why it is so great.

May I suggest writing a publicly viewable sample application that is fairly practical, not lab toys or programming contest entries; and then compare it to implimentations in non-Lisp languages and describe in detail why it is better.

For example, a college grade and course tracking system.

love php5

[wwmedia]

i love php5

recently upgraded my servers to php5.1.2 and mysql5 running on apache2

all my sites are programmed in OO php5 (i know it aint as good as java, but it does the job)

the speed increase has been phenomenal (i think mainly to php5 using references instead of passing by value)

i have a forum with 200 people on at any time with the server load barely above 1.0!! thats a celeron server as well!

Re:love php5

[Anonymous Coward]

Wow. 200 people. That's what, 5 requests per second?
And a load of 1.0...

Excellent!

[Anonymous Coward]

Now that PHP is as complex as Java, it's time to move on...

[OFF] Re:PHP's Comeupance

[biraneto2]

Well... that was funny I must say. But being a brazilian, a native portuguese speaker, I somehow feel offended by this kind of post (I even checked if the story category was english gramatics or something). I don't feel obligated to speak english perfectly when most americans also can't do it. But maybe I'm just over reacting...

Re:[OFF] Re:PHP's Comeupance

[Unski]

But maybe I'm just over reacting...

You are. That was note-perfect parody, amongst the finest I have ever seen and read. I struggled to breathe properly after reading his spoof.

Re:[OFF] Re:PHP's Comeupance

[caffeination]

You're really overreacting mate, especially since the kind of english being put down is the sort that's poor and lazy when the speaker could just as easily speak normal english. At least you included the word somehow as a handy comfort zone.
Now, how to take away the flamey tone of this reply? Common ground!

Re:PHP 4 V. 5

[masklinn]

Not enforcing Object Oriented programming is actually a very good thing, one of the few good things in PHP5.

Giving the option to use OOP (with a good object system, which PHP doesn't have) is good, forcing it on the poor user and preventing him to write as much as a line of code outside of a damn class is stupid, and is a god damn failure of both Java and C#.

While OOP is a good idea for some problem, others are better solved using more imperative or functional styles. That's why I much prefer Ruby or Python to Java: while they have great object models, they don't try to beat you with an ugly stick if you don't wrap every damn thing in a useless class that is only here because the language absolutely forbids you from doing otherwise.

Ruby?

[Some Random Username]

You mean kinda like every language that supports OO design? None of this is even remotely ruby specific, or even ruby inspired.

Re:Ruby?

[pkulak]

Really? So you can dynamically add methods to Java or C++ classes? How about Object Pascal? C#? Visual Basic? Maybe I should have said that it's like Ruby, Smalltalk and Python, but I figured Ruby, being the most popular right now, would be enough to get my point across.

Re:Ruby?

[Dr. Sp0ng]

... C#? Visual Basic? ...

Actually, yes. Objective-C, too.

Re:Ruby?

[Some Random Username]

C++, VB, C#, objective C, python, perl, pike, ruby, smalltalk, and likely several other languages I am not familiar enough with to comment on all can do this. Yep, sounds like ruby is pretty much on its own here huh?

Re:PHP 4 V. 5

[jo42]

Yeah, yer right, PHP5 doesn't force that New Age, Gay-Arsed stuff on you.

Re:PHP 4 V. 5

[jZnat]

Although, I still can't find a decent set of classes to generate cross-database SQL queries. Anything I've found has been way too bloated (e.g. integration with a bazillion PEAR classes, extending classes to make actual objects, etc), and the closest thing I've found so far is something I wrote in the first place, so it looks like I'm screwed here...

Re:PHP 4 V. 5

[kpdvx]

An OO interface to MySQL? Can you elaborate, as I've never seen this mentioned anywhere.

Re:PHP 4 V. 5

[lbft]

With the MySQLi extension (the 'i' stands for improved) you basically call methods on/read properties of a mysqli object rather than passing a resource to procedural functions, get a mysqli_stmt object when you prepare a statement, get a mysqli_result object back from a query, etc. It's clearer and neater than the old way and it opens up opportunities for using some of the newer features like iterators.

Sorry if it sounded like I meant that it does schema-reading magic and presents your tables to you as objects or something (although I don't doubt that there's code out there somewhere that does it, and it'd be very doable by implementing appropriate _get, _set and _call methods on your particular object. Look at the SOAP extension for an example of that sort of thing.)

Awful use of regex

[1110110001]

The call method has a preg_match, which is not needed and doesn't match right:

function __call($method, $args) {
  if(preg_match("/set_(.*)/", $method, $found )) {
    if(array_key_exists($found[1], $this->fields)) {
      $this->fields[$found[1]] = $args[0];
      return true;
    }
  } else if(preg_match("/get_(.*)/", $method, $found)) {
    if(array_key_exists($found[1], $this->fields)) {
      return $this->fields[ $found[1] ];
    }
  }
  return false;
}

There is so too much wrong with this simple method:

• Double quotes altough single qoutes would do it
• No circumflex at start of regex, thus somerandomshitset_foobar also matches
• Code is duplicated (array_key_exists)
• Null would fit much better if someone is trying to use a random name as getter, false could be a valid value for a field
• $args is used but not checked
• A string is splitted with an regex?!

Let's see how it can be done better:

function __call($method, $args) {
  list($type, $field) = explode('_', $method, 2);
  if(!isset($this->fields[$field])) {
    return null;
  }
  if($type == 'get') {
    return $this->fields[$field];
  }
  if($type == 'set' && isset($args[0])) {
    $this->fields[$field] = $args[0];
    return true;
  }
  return null;
}

Wow - Did ya ever think...

[CodeoRowboy]

you would live to see IBM become "hip" again in terms of technology? I can remember when they were the MS of the computer world - evil empire, monolithic - all that good stuff. Now they are like the mythic figure of Richard the Lionheart - ready to ride in and assist the open source Robin Hood.

CodeoRowboy
"The speed of light is faster than the speed of sound. That is why some people appear bright until you hear them speak."

While we're on the subject of OOP and PHP...

[cwf0621]

My firm is a fairly big fan of WASP (http://wasp.sourceforge.net/). Check it out.

This is BAAAAD juju: "The third solution..."

[spentrent]

The third solution, which I cover in this article, is to write a single class that dynamically molds itself at runtime to the fields of a given table. This class may perform a bit more slowly than its table-specific counterpart, but it saves me from having to write a lot of code. This solution is particularly beneficial at the start of a project, where tables and fields are changing constantly, and keeping up with rapid changes is crucial.

OK bro so I am a kitschy Perl programmer who loves invoking "Laziness" but this is TOOOOO much.

Now you can write code that is twice as shitty in half the time! And that's a feature?!?

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:PHP 4 V. 5

[tinkertim]

I look at the php executable much like I look at my kernel. How much crap is in there that I don't need.

Remember,

#!/bin/bash

can also be

#!/path/to/php -q

Given all of the ways you can build php you can achieve a really nice object oriented feature filled shell script (very useful to tear through logs with regex / etc) that has an executable about 1mb in size (that was php4 I haven't really ripped apart php5).

Build php like your going shopping for car parts. Hmm ok I need sockets, gd, zlib .. hmm better grab some curl.

I have 4 or 5 jobs running with 4 or 5 different versions of php. Perl was easier and is modular but the resulting footprint is much bigger.

This is very useful when you're trying to build something into a single board computer, or where you need to run something very often that parses a lot of text.. lots of good uses.

I (personally) don't use it yet for much else. My biggest hip hip horray about php5 is support for sqlite. But I plan to use that in php shell scripts anyway.

I dont eat breathe and live PHP .. so I have the luxury of enjoying what it does and not really missing what it doesn't. But it has some uses I didn't see mentioned, so I mentioned :)

Re:PHP 4 V. 5

[HaydnH]

While the fact you can now program in OO that hasn't really swayed my decision to move to 5 at all - what, am I going to rewrite all of my existing pages? Or rewrite functions I have ready to copy & paste when I next need them? Probably not.

The main reason I upgraded some of my sites to 5 was the addition of the imagefilter() function. I can now insert text using a ttf font in gray, use imagefilter() to gaussian blur the text a little and then add the new bit of text 'above' it to create nice drop shadowed text images on the fly - useful for dynamic sites.

Re:PHP 4 V. 5

[masklinn]

Remember,

#!/bin/bash

can also be

#!/path/to/php -q

Or #!/path/to/python, or #!/path/to/ruby. Your point?

PDO in v5.1

[PhYrE2k2]

Don't forget PDO in v5.1. It's a _GREAT_ feature, really simplifying database functionality for PostgreSQL, MySQL and others. The calls and itterators are really smart, and syntax is golden. It makes heavy use of exceptions. See http://www.php.net/pdo for more details and examples.

Re:PHP 4 V. 5

[hazah]

propel, a pear package http://propel.tigris.org/ does exactly that.

Re:LOL (Lisp)

[Anonymous Coward]

If you love Lisp so much, find a better way of selling it.

It's called Emacs.

There are three types of programmers: DevStudio/Xcode/Eclipse slaves, the above-average VI underachiver types and the Emacs intellectual porn stars :)

Now, back to creating Lisp modules so I can avoid Xcode and still create Universal Binaries.

Re:PHP 4 V. 5

[Anonymous Coward]

Actually, to get real specific, if you aren't doing anything too heavy just realize that you have to downgrade from public and pivate class variable creation to generic creat.

So. Just do a word filter for "private" and "public" and change them to "var".

Re:PHP 4 V. 5

[Anonymous Coward]

This week I started experimenting with PHP and mysql. To my shock, horror and dismay, I found out that my ISP isn't running the latest of either. This means that all the common examples fail spectacularly. Rhetorical question: that good are new features in PHP 5 and mysql 5 if you can't use them?

Unfortunately it appears that "most" ISPs (note the quotes -- this is a made up figure based on my own experience) have no plans of upgrading past PHP 4.3.x and mysql 4.0.x anytime soon.

One of my gripe here is with the mentality that it's okay to release a new major version of an interpreter without renaming the language. We've seen this with Java (most users are stuck at or below 1.4, but most web stuff requires 1.5 or higher) and perl (though to be fair, they haven't released perl6 yet so they still have a chance to rename it to avoid confusion).

Another thing that bothers me about PHP is the fact that there are so many configuration options that you have to implictly depend upon. If someone changes one of these behind your back, your scripts will start misbehaving in odd ways. To make matters worse, dozens of the defaults change from one version of PHP to the next (even between minor versions).

But it's a love/hate relationship so far. I really do like the ease of use: just write some HTML and slap in a oneliner to import some code at the right spot. However, it annoys me that it's so difficult to make anything even half way robust.