Keith Devens .com

THANK YOU! I had the weirdest bug in an XML parsing class I wrote recently: for some reason, calls to update and check a property of the class just weren't working. I spent 2 days pulling my hair out about it before cludging it with a global variable (ugh) and moving on. I've just added the & to the $this in my xml_set_element_handler calls and now it works fine.

I am so looking forward to PHP5.

Heh, then maybe you can help me get mine to work...

The worst thing about all this is that I had (and still have, of course) code that works, but that I have to waste hours of my life rewriting because someone (apparently arbitrarily) decided to deprecate a feature without considering the consequences.

Well, I can relate to the "reference angst" in PHP. It's currently very confusing, though it's not a very new situation. Reference support until now has always been sketchy and impartial. What strikes me particularly as odd is the relationship between arrays and references. For instance,

$foo->test(array(&$bar));

where bar is an object does NOT trigger the default error warning. I don't know if it rather should or not, or if it's a perfectly legal PHP statement. Anyway, wrapping a one-element array around the variable enables provides a kludge for optionally passing references, if test() looks like this:

function test($param = null) {
if (isset($param)) {
$param[0]->add('hi');
}
}

PHP horrid? Perhaps. Inconsistent? Indeed.

I hate PHP

Now there's something all of us, liberal or conservative, can agree on.

Definitely inconsistent. So much so that I constantly have to look to the reference to find out which functions take parameters in which order, since "needle" and "haystack" are so often reversed.

"Horrid" includes other major pain in the butt features like magic_quotes, trans_sid, etc.

Ben,

The reason for that is that a copy of the array is made (including a copy of the reference).

Inconsistency and bad planning are my two main gripes with PHP. Magic quotes, for example. "I know, let's put backslashes into strings from the user, just on the off-chance that the author is going to dump them into a database without quoting them! Who cares about sane authors?"

Not to mention the fact that it's impossible to use nl2br() with current versions of PHP and valid HTML (it only generates XHTML-style br elements).

Not to mention the fact that it's impossible to use nl2br() with current versions of PHP and valid HTML (it only generates XHTML-style br elements).

Yeah, and highlight_string, et al, still use <font> tags to do the highlighting. In my markup library, where I want to allow PHP code highlighting, I had to do a regular expression replacement on the generated string to replace '<font color="' with '<span style="color: ' and '</font>' with '</span>'.

Actually, I don't know what your problem is with XHTML style <br /> tags. AFAIK, they should work with everything... that's a feature, not a problem. I didn't read your comment carefully enough originally.

Grr... one more correction. I didn't do a regular expression replacement like I said above... just a plain string replacement.

call time pass by reference is sometimes necessary, in this case just use it. You'll only get these errors if you are using E_NOTICE. E_NOTICE just tells you cases where you could be doing something that is possibly wrong, not necessarily wrong.

Its sorta like: "Tell me when I might be doing something stupid mode." It doesn't mean you actually did something wrong.

Most of the object inconsistencies will be fixed in PHP5, btw.

At first I thought they were notices, but since the error messages said "Warning:" and not "Notice:" I figured they were E_WARNING level messages. Thanks Sterling, I may just go and turn off E_NOTICE's for those and save myself the headache.

The problem, for people like me who want to write libraries, is that we can't just worry about our own configurations. So for every function I may have to turn off error_reporting() of E_NOTICES.

Sterling, do you know why call-time pass-by-reference was deprecated in the first place?

If you're looking for some entertainment, how about trying HTMLSax instead?

Thanks to some great input via Sitepointforums, managed to get it ramped up to be almost as fast as the native PHP XML extension. I've also done my best to make the API as similar as possible so it should mean only minor modifications to a class currently using Expat. Thats the downside though - the handlers must be available via an object. Oh and HTMLSax wont warn you if the XML was badly formed.

But $parser->set_object($this) will mean $this is referenced...

Hi Keith,

Well I'll definitely agree with you on php's inconsistencies. They suck. But different languages work for different folks. PHP works for me so I'll stay with it. It does sound like you're just not happy and maybe Python is a better place for you (though it would be a shame to lose you although I'll benefit since I'll learn from your learning process (and blogging about it)).

Best
Scott

Personally I prefer ruby though I do a lot of plugin development in PHP for nucleus.

Just wanted to update this post: The errors given to complain about call time pass by refererce are definitely E_WARNINGs and not E_NOTICEs.

about PHP being inconsistent, I can only agree

see http://tnx.nl/php.txt for more

Hey, I think that's the article I linked to here, but the link broke almost immediately.

Workaround for "Call-time pass-by-reference has been deprecated":

call_user_func_array(array(&$obj,$method),array(&$arg1,$arg2));

I find it funny that this site is powered by PHP.

Language vs. platform man.

I just was curious about PHP, since our apprentice loves it a lot... So far, I resisted to touch anything else than Perl and Bourne Shell, and I'm happy with it. "Give the customer what he wants, not what he needs" - oh god, I'm sick of it. I've seen guys claiming to be pros in any known language. The first Perl snippets I encountered said all enough...

Ah, PHP is perfectly suited for the unexperienced, wannabe hacker. Yes, you get some results quickly. Just an example which gave me a really bad impression about PHP: Compare PHP's DB stuff with Perl's DBI interface.

Stick at your programming language of your choice, and really learn how to code. Keep it simple (not stupid, simple . Write concepts. End up with clean, well commented code, and enjoy!

Cheers from Switzerland,
tomm