Upgrading scripts to conform to PHP 4.4 ref. implementation

[arborint]

Off Topic:

arborint, DIV might stand for "division" but in terms of HTML markup it is quite meaningless. There are some simple rules like it cannot be inside of a paragraph, but its actual function is meaningless on its own, unlike other tags. The same is true for SPAN as well. They are simply nothing more than generic containers, and you have to give them meaning and shape. That was simply my point there, that they are in fact quite meaningless in the markup and there is nothing wrong with that

Off Topic:

Again, I don't see where they are meaningless. DIV and SPAN have very specific rules that are derived from hundreds of years of practice in page layout. They did not just appear as a couple of randomly named, extra placeholder tags that are meaningless -- their names have specific meanings and those meanings are appropriate for the usage of each of those tags. They are for two common types of non-paragraph text blocks. The fact that their names are also appropriate to describe blocks that Gutenberg never dreamed of simply shows the power of good naming.

[stereofrog]

I've read Derick Rethans's article on references and have a strange feeling that even core developers have, at best, fuzzy understanding on what's going on there. Again, it's no wonder that "return $a=1" doesn't work, but it' really astonishing that "foo($a=1)" does.

As to naming of return paramters etc, it reminds me of Pascal/VB convention where you have to assign return value to the function name:

function FooBar : Integer;
begin
   FooBar := 2 * 2;
end;

[dreamscape]

Off Topic:

arborint, I really hate argue with you but yes they essentially are meaningless. The W3C defines them as "generic containers". If I have <p>something</p> that on its own has meaning. I know it is a paragraph, and that is what its role in the document is. If I have <em>somthing</em> I know what that is, it has a very specific meaning and role. The same is true with most other tags. However, if I have <div>something</div>, it doesn't have any kind of real or specific meaning. You cannot tell what role it plays in the document just by looking at it, because it has no real role, other than being a "generic block level container". DIV *may* have been meant for a "non-paragraph text block" in HTML 3, but that isn't true, even with the now old HTML 4.0 that is not its definition, and that is certainly not its role in XHTML. It could be a layer in a stack of layers to generate some rendering effect, it could draw a line, it could hold an image, it could hold space, it could hold a bunch of paragraphs as you say its purpose is, or it could be a lot of other things, but its role is not concrete; not like other tags. It IS a generic tag. That IS its definition according to the W3C, and practically that means that it is utterly meaningless on its own. YOU have to give it meaning in the docment.

[AutisticCuckoo]

Off Topic:

A DIV is a generic division within the page. It's semantically weaker than most elements, but it's not meaningless. It groups related elements together. Similarly, but perhaps even weaker, a SPAN identifies a part of the content which has some common characteristics for which there is no semantic element type available.

[jayboots]

Again, it's no wonder that "return $a=1" doesn't work, but it' really astonishing that "foo($a=1)" does.

Why is that astonishing? As long as foo returns a reference and as long as the first parameter DOES NOT accept a reference, that makes perfect sense -- you are passing a value as a parameter to a function that returns a reference.

[AutisticCuckoo]

No, that's the odd thing here: foo($a=1) works even if the function is defined like this:

function foo(&$param) 

It seems like assignments are evaluated first in a function call, and that the variables themselves are then used when calling the actual function. This is a bit counter-intuitive for an old C programmer. I would expect foo($a=1) to be equivalent to

$a = 1;
foo(1); 

since the result of an assignment should be the assigned value, not the variable to which the value was assigned.

[jayboots]

No, that's the odd thing here: foo($a=1) works even if the function is defined like this:

function foo(&$param) 

I see the light -- and it is astonishing! I'll just add that to my list of pet php peeves. The funny thing is, no single item on the list is a show-breaker in-itself for me but the list in total is getting unwieldly. :'(

[sweatje]

I see the light -- and it is astonishing! I'll just add that to my list of pet php peeves. The funny thing is, no single item on the list is a show-breaker in-itself for me but the list in total is getting unwieldly. :'(

That about sums up my basic feelings. The cognative disonance associated with maintaining php4 and php5 compatible scripts correctly handling php4 objects by ref is getting to be a PITA.

[REMIYA]

If you do something by using references in PHP, reconsider your code. Perhaps there is somethig wrong with it. There is rarely a need to use them.

Of course, if you want to do it, you can, but at some point, sooner or later, you will deeply regret about your decission.

[sweatje]

If you do something by using references in PHP, reconsider your code. Perhaps there is somethig wrong with it. There is rarely a need to use them.

Of course, if you want to do it, you can, but at some point, sooner or later, you will deeply regret about your decission.

You must be rarely using OOP in PHP4 then

[Super Phil]

So just so I'm clear - PHP5 is still passing objects/arrays by references automagically, riight?

[REMIYA]

That is really true. But sometimes it can be escaped. Some people use references, even if they have the possibility no to use them, thinking it is the easy way out. Then at some point, they find a mistake coming from nowhere, and they blame the references for this.

[sweatje]

So just so I'm clear - PHP5 is still passing objects/arrays by references automagically, riight?

Neither is passed by reference automatically in php5. Variables now store object handles (kind of like a file handle) so you no longer have to worry about passing them by reference the way you did in php4.

[jayboots]

...and to continue sweatje's comment, arrays were never passed-by-ref except explicitly. The copy-on-write semantics still apply, so if you are only doing read-only of a passed array then passing by-value is essentially equivalent to passing by-reference. This fails to hold if you write to the passed array. This is still true in PHP5.

[arborint]

That about sums up my basic feelings. The cognative disonance associated with maintaining php4 and php5 compatible scripts correctly handling php4 objects by ref is getting to be a PITA.

This in may ways is really the problem with PHP since PHP5. And looking at the PHP6 list it seems like there is more noise being added rather than actually tightening up the language and improving the object model.

If you look at references, they came about because there was internal optimization code to reduce memory usage that made use of references. So the '&' was added to force the parser to always create a reference, rather than only up until the value was changed. It was a natural and easy addition because of the existing code -- but are we sure it was a good one? Perhaps references should be ditched and a clean, true handle implementation added.

Just because a clean way can be technically found to add a feature does not mean that the feature should be added or in that way.

[jayboots]

Off Topic:

This in may ways is really the problem with PHP since PHP5. And looking at the PHP6 list it seems like there is more noise being added rather than actually tightening up the language and improving the object model.

My problem with this proposition is this: if you need 100% BC to PHP4, use the 100% BC environment that your PHP4 code was developed on -- PHP4. Otherwise migrate your codebase to PHP5. If this means two different code-bases (at least in the short term), so be it. Note that PHP is currently supporting two main release branches as well -- one for PHP4 and one for PHP5.

It is not impossible to make PHP4 scripts work in a PHP5 environment -- but unless you intend to use PHP5 features, why bother? Which means, why bother running PHP5 at all if you are still targetting PHP4? Same for PHP6 -- there is still much trash and fat that can be trimmed. Let them do it and then use a controlled process to migrate your scripts as needed.

Let's face it: the people who seem to be having the most problems with PHP4/PHP5 codebases are those who are trying to use intermediate to advanced OOP techniques. Traditional PHP4 scripts did not rely heavily on objects for good reasons (to be delicate, PHP4's object support was, erm, unsophisticated). As people pushed it and started to use PHP4 in non-traditional ways (ie: OOP heavy), PHP5 was born to help address the issues they were running into. It is ironic that people are complaining that the PHP4 OOP idioms are not well supported when in reality, it is a blessing that they are being left behind. By-and-large they were inelegant if not outright hacky. Should all PHP4 code work on PHP5? I think that the best one should hope for is that the majority of procedural, non-object heavy stuff will. In my mind, PHP5 does even better than that.

To me, PHP 5.1 is the best PHP ever and it is the only version that any of my more recent code targets. Perhaps that is a luxury that others don't have; what I'm suggesting is that if you don't have that luxury, either stick with PHP4 until you do have the capability to migrate or go ahead and maintain two separate codebases. It is folly to think you can swim in two ponds at once.

Greetings.

[arborint]

Off Topic:

My problem with this proposition is this: if you need 100% BC to PHP4, use the 100% BC environment that your PHP4 code was developed on -- PHP4. Otherwise migrate your codebase to PHP5. If this means two different code-bases (at least in the short term), so be it. Note that PHP is currently supporting two main release branches as well -- one for PHP4 and one for PHP5

I really was not talking about BC, but was addressing language design itself. I don't mind BC breaks if the language is improving. But BC breaks to patch up something that might have been a bad idea in the first place is just misery to no end.

One if the things I have wondered about is the PHP Group's attitude to BC. They seem to think that showing a warning the way to go. I am not sure of the preformance implications, but it seems like a separate tool that wouild identify and help with BC problems would be better that having PHP be a giant warning machine. A separate tool could even automate some of the tedious upgrading.

[sweatje]

One if the things I have wondered about is the PHP Group's attitude to BC. They seem to think that showing a warning the way to go. I am not sure of the preformance implications, but it seems like a separate tool that wouild identify and help with BC problems would be better that having PHP be a giant warning machine. A separate tool could even automate some of the tedious upgrading.

For "compiled time" stuff there is php lint mode:

$ php -d error_reporting=4095 -l script_to_check.php

which works pretty well.

[jayboots]

One if the things I have wondered about is the PHP Group's attitude to BC. They seem to think that showing a warning the way to go. I am not sure of the preformance implications, but it seems like a separate tool that wouild identify and help with BC problems would be better that having PHP be a giant warning machine. A separate tool could even automate some of the tedious upgrading.

I completely agree on this. As far as I'm concerned, PHP has a lint mode and that is where those stupid E_STRICTs should be shown -- or in a separate log turned on via a separate ini switch (I have written and asked for this back when but you can imagine the response I got). The runtime should never, ever, stop to tell me that something is wrong unless it is something that is so wrong, that it can't do its job -- run my code!

(okay, I like E_STRICT notices because they help me find where I need to adjust my code, but I still don't want notices like that coming from the runtime -- not ever. Note, this is not the same for E_NOTICE which is a runtime issue).

As for BC breaks to fix what was questionable to begin with -- other than for fixing serious bugs (ie: the reason for the 4.4 release and the issue behind the change that sparked this thread) what better reason is there for a BC break than to fix a bad design? Or perhaps I read you wrong again. I suspect that either way, we are in similar camps after all

[Etnu]

Step 1: Ask yourself if you actually have a legitimate reason to be returning by reference. There are only 2 reasons:

1.) It's an object reference (PHP4 handles objects stupidly)
2.) It's a value that you actually want to have modified.

Unlike other languages, PHP uses copy on modify behavior -- which means that passing a variable by reference to avoid a copy being made (except in the case of objects in PHP 4) offers no performance benefits.

Step 2: If you have code that could potentially be returning non-variables by reference, analyze the code itself, because there's a high degree of likelyhood that you're doing something funky, although there are certainly plenty of cases where you'd be returning a value such as NULL (I maintain that null should ALWAYS be "ok" to pass by reference, and I wish there were some way to treat PHP's reference more like C++ pointers in that respect).

Step 3: If you can, upgrade to PHP 5 and eliminate the need for the vast majority of reference passing (not just because objects are "fixed", but because you can just throw exceptions in the case that a valid reference can't be returned, which is a much more elegant solution than constant value checking).

[sweatje]

This whole discussion makes me wonder how hard it would be to back-port object handles to php4. My c is incredibly rusty, and I have no clue how the internals of php are structured so I can't really comment one way or another, but it sure seems like we could kill a lot of the reference incompatability with php5 by performaing that backport (+ clone for when you really need a copy).

[jayboots]

This whole discussion makes me wonder how hard it would be to back-port object handles to php4. My c is incredibly rusty, and I have no clue how the internals of php are structured so I can't really comment one way or another, but it sure seems like we could kill a lot of the reference incompatability with php5 by performaing that backport (+ clone for when you really need a copy).

Wouldn't that still "break" a lot of existing PHP4 code? It occurs to me that the only compatability this would gain is for "new" PHP4 code -- and why not just target PHP5 when writing new code? Especially since the "new" code wouldn't be compatible with previous versions of PHP4 that did not have those semantics. Probably moot anyhow as you already know that the 4.x branch is supposedly closed to new features being accepted

[Carl]

At the same time the following code works just fine:

function foo(&$arr) {
  $arr[] = 3;
}

foo($arr = array(1, 2)); 

remember PHP works from th inside out. There is no reason that this should not work unless you remove the construct or "square bracket" method "[]" $arr. The construct method only does two things, check to see if the array exists and if not creates it. If the array exists then it assigns whatever the code says to the end of the array. It does not look inside the array so much as the array() function ([] does check for index type). Which is why it is so much faster to use when initializing an array.

function foo(&$arr) {// (3) reference to variable $arr
  $arr[] = 3; //(4) use construct to add on to $arr because it already exists
}

foo($arr = array(1, 2));// (1)$arr is initialized and set into memory(2) call to foo() 

[pachanga]

There is no reason that this should not work unless you remove the construct or "square bracket" method "[]" $arr....

I think you're missing the whole point of the discussion.... It's about references usage issues not about proper array usage.

[asp_funda]

Damn, just when I thought I understood variables and references

erm, reading this thread is making my head spin!! I feel like I don't even know what PHP is!!