SitePoint Sponsor

User Tag List

Page 1 of 3 123 LastLast
Results 1 to 25 of 72

Hybrid View

  1. #1
    SitePoint Member
    Join Date
    Jul 2005
    Posts
    24
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    PHP 4.4.0 BC workaround for - Only variables should be assigned by reference

    hello,

    aside from setting error_reporting(E_ALL & ~E_NOTICE) what other alternatives are there?

    all PHP4 code using OOP almost always uses

    PHP Code:
    function &getInstance() {
       return 
    ClassName::getFunction();
    }

    $a =& getInstance(); 
    all code likes this is harmed, and i don't really like setting E_NOTICE off.

  2. #2
    SitePoint Addict
    Join Date
    May 2005
    Posts
    255
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You do realize that that when the notice is generated, the value gets passed by value anyway, right? In short, removing the reference operators will have no effect.

  3. #3
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Downgrade to 4.3.11.
    Or rewrite your code to
    PHP Code:
    function & getInstance() {
        
    $tmp =& ClassName::getFunction();
        return 
    $tmp;

    Seriously. Why on earth did the php-developers choose to break backward compatibility in a maintenancerelease ? Beats me.

  4. #4
    SitePoint Member
    Join Date
    Jul 2005
    Posts
    24
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You do realize that that when the notice is generated, the value gets passed by value anyway, right? In short, removing the reference operators will have no effect.
    on the contrary i tried unit testing it (with E_NOTICE off) and assertReference holds when using the old method, and fails when i remove the "&"s.

    and even if its true i wouldn't want the hassle of hacking away at the framework code (WACT).

    So there's no other way to prevent this? I like E_NOTICE errors since it makes you code cleaner. As of now i replaced the php4ts.dll and php4apache2.dll with the php 4.3.11 version to prevent this.

    Lastly, why does it report a notice in PHP 4.4.0 and not report one in PHP 5.0.4. Seems very weird and uncalled for.

  5. #5
    SitePoint Addict
    Join Date
    May 2005
    Posts
    255
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by gaialucien
    on the contrary i tried unit testing it (with E_NOTICE off) and assertReference holds when using the old method, and fails when i remove the "&"s.

    and even if its true i wouldn't want the hassle of hacking away at the framework code (WACT).

    So there's no other way to prevent this? I like E_NOTICE errors since it makes you code cleaner. As of now i replaced the php4ts.dll and php4apache2.dll with the php 4.3.11 version to prevent this.

    Lastly, why does it report a notice in PHP 4.4.0 and not report one in PHP 5.0.4. Seems very weird and uncalled for.
    Because 4.4 was released after 5.0.4.

    It's a *FATAL ERROR* in 5.1

    They "chose" to break BC because there's only 2 workarounds:

    1.) let a memory leak take place on half the calls.

    2.) Write hacked code that automatically generates temp vars for passing things around, which would add extra overhead to every function call. (Yeuch!)

  6. #6
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Etnu
    They "chose" to break BC because there's only 2 workarounds:

    1.) let a memory leak take place on half the calls.

    2.) Write hacked code that automatically generates temp vars for passing things around, which would add extra overhead to every function call. (Yeuch!)
    So you abide ? As a user I don't really care what the technical explanation is, I just want it to work. And it doesn't.
    Tell me why I should upgrade to 4.4, rather than 5.0.4 ?

  7. #7
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by Etnu
    2.) Write hacked code that automatically generates temp vars for passing things around, which would add extra overhead to every function call. (Yeuch!)
    They should have gone for this option. The temp variable is not needed for every call in PHP5, in fact none as far as I can see, as the & doesn't change behaviour in this case.

    Even in PHP4 I cannot see he ambiguity and just from looking at the code it is pretty obvious what is intended. That's not to say there aren't obscure cases, but a simple heuristic would have avoided temps. This way we have to put the temps in ourselves, which add source code which adds an even bigger overhead.

    I have a whole bunch of projects that cannot upgrade to PHP4.4 right now, because of this screw up. Why is it that PHPers have to suffer this idiocy and no one else?

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  8. #8
    SitePoint Enthusiast dgx's Avatar
    Join Date
    Aug 2005
    Location
    The Czech Republic
    Posts
    25
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    That's just I started think about complex workaround, this is result.

  9. #9
    SitePoint Addict
    Join Date
    May 2005
    Posts
    255
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    Hi...



    They should have gone for this option. The temp variable is not needed for every call in PHP5, in fact none as far as I can see, as the & doesn't change behaviour in this case.

    Even in PHP4 I cannot see he ambiguity and just from looking at the code it is pretty obvious what is intended. That's not to say there aren't obscure cases, but a simple heuristic would have avoided temps. This way we have to put the temps in ourselves, which add source code which adds an even bigger overhead.

    I have a whole bunch of projects that cannot upgrade to PHP4.4 right now, because of this screw up. Why is it that PHPers have to suffer this idiocy and no one else?

    yours, Marcus
    You just suggested that they penalize the entire PHP user base (by degrading performance) to compensate for *bad code* written by a few users. You're actually experiencing bigger problems (a memory leak) by not fixing the code.

    So you abide ? As a user I don't really care what the technical explanation is, I just want it to work. And it doesn't.
    Tell me why I should upgrade to 4.4, rather than 5.0.4 ?
    As a developer, I want my internals working correctly and efficiently. As a developer, I should take it upon myself to fix my application before releasing a new version. If you're just a user who runs applications (and doesn't do development work), why do you even care which version of PHP you're running?

  10. #10
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,627
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    I would argue that 4.4 vs 4.3.12 indicates there could be breaking changes. In any case, crap like this is why I stopped using PHP.

  11. #11
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If there are language incompatibilities between language versions, than it's up to us, the developer to find a workaround is how I see it at the end of the day. A client isn't and shouldn't be concerned about the trials and tribulations of our working life.

    Get over it. Period.

  12. #12
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by Dr Livingston
    If there are language incompatibilities between language versions, than it's up to us, the developer to find a workaround is how I see it at the end of the day. A client isn't and shouldn't be concerned about the trials and tribulations of our working life.
    So now I have to go back to completed jobs and tell them that I have to do two to four weeks work on the code so that their next "security patch" doesn't spew a load of error messages all over the place? Who should pay for this? The client? Me? Or how about Zend?

    Quote Originally Posted by Dr Livingston
    Get over it. Period.
    Is it that you don't have any completed projects, or you don't have any past clients? Your reaction is odd to say the least.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  13. #13
    SitePoint Addict
    Join Date
    May 2005
    Posts
    255
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    Hi...



    So now I have to go back to completed jobs and tell them that I have to do two to four weeks work on the code so that their next "security patch" doesn't spew a load of error messages all over the place? Who should pay for this? The client? Me? Or how about Zend?



    Is it that you don't have any completed projects, or you don't have any past clients? Your reaction is odd to say the least.

    yours, Marcus
    You. Good code shouldn't have stuff like that in the first place. Any good programmer knows that you don't return values by reference when there's a possibility of an invalid reference being used. You try that in other languages (C++ comes to mind as being particularly painful), and you'll be wishing PHP was so gentle.

    And any time you want to do sane object oriented development in PHP
    Partially true, although you still won't encounter these types of issues if you wrote your code right. The ampersands are no longer "necessary", but they still work without modification if you programmed things correctly when moving to PHP5. Well-written php4 code runs perfectly fine on PHP5 setups without modification. I've got at least 5 major applications under my belt that were heavily OO (in PHP4) that had no problems at all. I'm upgrading most of them to PHP5 now, not because things are breaking, but to take advantage of the new constructs, extra performance, and enhanced extensions (particularly mysqli).

    I don't want to return a pointer, just a normal reference. PHP is a high level language, we shouldn't need to worry about this sort of stuff - that's why we are using a high level language!
    You're not dealing with a pointer. You're dealing with a simple logical falacy.

    The examples where this fails is in situations where you're returning a reference to something which is potentially a non-variable (e.g. a reference to the number 4, or 0 as is the more common case...). How do you handle a reference to a number? Should I be allowed to set the literal 4 to some other value? Of course not.

    Writing a reference-counting mechanism that can handle those situations is going to be so messy that it's simply not worth the effort, and that's essentially what the original complaint in this thread was doing (albeit the problem there was a potential failure when using the new operator).

    Obviously this is an example made to illustrate a point and isn't very realistic, but hopefully it explains why there's a problem here. They fixed a BUG in the language that NEVER should have existed in the first place. They generated a GENTLE NUDGE to get people to fix these things in their code. Good code won't be written this way in the first place. You should never return a non-variable by reference -- period. It just shouldn't happen.

    Of course, this is a silly argument anyway. They're not going to change it back to the old, broken implementation, and people will have to fix their buggy code (unless of course they're really keen on the idea of sticking with old technology). This is the way the language works now.

    By the way -- the problem isn't "solved" by upgrading to PHP5. 5.0.5 and 5.1 both have the bug fixed, and 5.0.4 doesn't offer any real advantage to users of 4.0.3 who aren't planning on doing PHP5 programming anyway.

  14. #14
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by Etnu
    Good code shouldn't have stuff like that in the first place.
    I thought I had explained this. The code quoted is correct both by the documentation of the day and also by what every other language is capable of. PHP5 copes with both value objects and reference objects even without the ampersands.

    Good languages shouldn't have stuff like this in the first place. As I said above, you hardly need wizardly C skills to avoid problems.

    Quote Originally Posted by Etnu
    Any good programmer knows that you don't return values by reference when there's a possibility of an invalid reference being used.
    You are sounding increasingly shrill. How unpopular do you want to make yourself? Good developers know what they are letting themselves in for when they use an ampersand.

    Quote Originally Posted by Etnu
    You try that in other languages (C++ comes to mind as being particularly painful), and you'll be wishing PHP was so gentle.
    It's a pretty standard operation to make a value object in C++. That's what the copy constructor is for. Do I need to post even more code?

    Quote Originally Posted by Etnu
    I've got at least 5 major applications under my belt that were heavily OO (in PHP4) that had no problems at all.
    Guess what? So has just about everyone else on the advanced forum.

    Quote Originally Posted by Etnu
    You're not dealing with a pointer. You're dealing with a simple logical falacy.
    That fallacy is needed for a good many design patterns: Observer, Registry, MockObjects, Singleton...

    Quote Originally Posted by Etnu
    How do you handle a reference to a number? Should I be allowed to set the literal 4 to some other value? Of course not.
    PHP5 manages fine, as does just about every other modern dynamic language. This is peculiar to PHP 4.4.

    Quote Originally Posted by Etnu
    Writing a reference-counting mechanism that can handle those situations is going to be so messy that it's simply not worth the effort,
    What has this got to do with reference counting?

    And I would like to think a dozen lines of reference counting code would be worth the effort not inflict BC breaks on just about every library out there. More likely they have had some essential stuff missing from the C structures that define the types. That would have inflicted the pain on all of the module writers out there.

    Zend are probably closer to those authors...

    Quote Originally Posted by Etnu
    You should never return a non-variable by reference -- period. It just shouldn't happen.
    If a developer does this without knowing, then I have no objection to the langauge complaining. Unfortunately it complains regardless. When the developers get it right, and "good" developers do, there should not be a problem. This is what makes PHP4.4 so broken. It forces the developer to add application code to make up for the inadequacies of the internals.

    I think it's the arrogance of this that has provoked the reaction that it has received.

    Quote Originally Posted by Etnu
    They're not going to change it back to the old, broken implementation,
    No, but they could fix the new broken implementation. Better yet, they could have fixed it before releasing 4.4.

    Quote Originally Posted by Etnu
    By the way -- the problem isn't "solved" by upgrading to PHP5. 5.0.5 and 5.1 both have the bug fixed, and 5.0.4 doesn't offer any real advantage to users of 4.0.3 who aren't planning on doing PHP5 programming anyway.
    5.0.4 add exceptions, removes references, add interfaces, etc, etc. I can think of lot's of reasons to upgrade. PHP5 is not the issue, as most applications will have work done on them for that upgrade. The problem is the PHP4 upgrade path is now rammed into the buffers until a lot of (unecessary) code is added.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  15. #15
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Etnu
    Any good programmer knows that you don't return values by reference when there's a possibility of an invalid reference being used.
    I'm a bad programmer by this criterion, but not terribly embarrassed.

    Most languages nowadays don't even give you a choice about it. Why should I have to know unless I use the languages that do?
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  16. #16
    SitePoint Evangelist
    Join Date
    Jun 2003
    Location
    Melbourne, Australia
    Posts
    440
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I know almost nothing about language internals, but there is something blindingly obvious here...
    Quote Originally Posted by Etnu
    The examples where this fails is in situations where you're returning a reference to something which is potentially a non-variable (e.g. a reference to the number 4, or 0 as is the more common case...). How do you handle a reference to a number? Should I be allowed to set the literal 4 to some other value? Of course not.
    One never could do something like:
    PHP Code:
    <?php

    class Thing {
        function &
    getWhatever() {
            return 
    4;
        }
    }

    ?>
    But the presence of the word 'new'...
    PHP Code:
    <?php

    class Whatever {}

    class 
    Thing {
        function &
    getAThing() {
            return new 
    Whatever;
        }
    }

    ?>
    ought to indicate that the returned variable is something to which a reference can be made. Forget the ideology... Why shouldn't PHP afford us this convenience?
    Zealotry is contingent upon 100 posts and addiction 200?

  17. #17
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Actually, I'd suggest doing away with the &foo(), install php5, and not think about it again.


    I just cannot understand what all the noise is about BC anyways? If you are upgrading to PHP5 in the forseeable future, just dump your old, antiquated PHP4.x script base, and start again afresh with PHP5.

    It may seam to be more trouble to do so programmatically and financially but really, it isn't. Just sit down and think about it huh? ... Are there parts of your script base that you wanted to refactor for example, but didn't quite get around to it?

    Well, here is your chance to just do that refactoring, during a new script development If you think your going to remain with PHP4.whatever it is nowadays, as I just couldn't give a flying ... , then what are you worrying all about for...

    You've choosen to remain in the dark ages

  18. #18
    SitePoint Wizard dreamscape's Avatar
    Join Date
    Aug 2005
    Posts
    1,080
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    >> I just cannot understand what all the noise is about BC anyways?

    The point is, you have 4.3.11, one would expect that a 4.4 "bug fix" release would be fairly compatible. However, it breaks so much, it begs the question, why the hell was it released as a 4.x anyways?

    And if your application contains, oh say like over 3,000 files, then it take a little more than just sitting down... it takes alot of sitting down

  19. #19
    SitePoint Addict timvw's Avatar
    Join Date
    Jan 2005
    Location
    Belgium
    Posts
    354
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    <troll>
    If you have to make the switch anyway.. It might be a good time to consider some environment that is capable to deliver the requirements you have. Today. And that will keep delivering them, without braking stuff when they provide a "bug fix".

    I don't understand why you would want to switch to PHP5 if you already know that PHP6 is likely to break things AGAIN. Ok, it ensures that you will have a migrating php5 to php6 job in a couple of years. Is that what they mean with PHP is enterprise ready?

    Who cares that php6 will have the best unicode support if you need it now? Who cares they will throw out magic_ and replace it with input_ and output_ stuff? Who cares they want to throw out safe_mode?

    I don't like the way the API is going either. I hate it to see they provide a "procedural" and an "oop" way to do exactly the same thing. At least one of them isn't the right way to do it.
    </troll>

  20. #20
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by timvw
    If you have to make the switch anyway...
    Despite my last post, I think people are more worried that a +0.1 release broke BC instead of fixing a bug, rather than a +1.0 release breaking BC to add features to the language.

    Douglas
    Hello World

  21. #21
    SitePoint Wizard dreamscape's Avatar
    Join Date
    Aug 2005
    Posts
    1,080
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    >> At least one of them isn't the right way to do it.

    Incase you haven't lived enough yet, there is not such thing as "right" in reality. And there sure as hell isn't only one way to do something.

  22. #22
    SitePoint Wizard dreamscape's Avatar
    Join Date
    Aug 2005
    Posts
    1,080
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    >> But really, references are broke anyway:

    And just how is that broken? The PHP Docs clearly state that doing that will break the reference between $b and $a. Unless by broken, you mean "works how the docs say it will," then that example is not broken.... because it works exactly how the docs tells you it will.

    References in PHP are not pointers... even the manual stresses this. In your example, $b does not point to $a; It merely refers to the same "place" that $a does. When you then make $b reference $c, it now refers to the same "place" that $c does. Since $a does not refer to this place, anything you do to $a after you switch $b's reference, has no effect on $b now.

    References are not like C pointers, and they are not supposed to be like C pointers. If you think this is broken, then that is because you don't understand what references in PHP are.

    Your supposed "broken" example does not work because:
    PHP Code:
    // $a refers to a place with value "a"
    $a 'a';

    // $b refers to same place $a does (value is "a")
    $b =& $a;

    // place $a refers to now has value of "b"
    // $b, referring to this same place, now also has a value of "b"
    $a 'b';

    // $c refers to a place with a value of "c"
    $c 'c';

    // $b now refers to the same place $c does,
    // and has a value of "c" now.
    // $b no longer refers to the same place $a does
    $b =& $c;

    // place $a refers to now has value of "a"
    $a 'a';

    // end result is that
    // $a = "a"
    // $b = "c"
    // $c = "c"
    // This is correct and exactly, without error, how references in PHP work 
    Read the manual... it falls over itself explaining this: http://us3.php.net/manual/en/language.references.php

    If you want $a, $b, and $c to all refer to the same place, you would do:
    PHP Code:
    $a 'a';
    $b =& $a;
    $a 'b';
    $c =& $a;
    $c 'c'
    While I agree with you that 4.4 shouldn't have broken compatibility with 4.3, I can't agree with you that because references work as advertised, they are broken

  23. #23
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dreamscape
    >> But really, references are broke anyway:

    And just how is that broken? The PHP Docs clearly state that doing that will break the reference between $b and $a. Unless by broken, you mean "works how the docs say it will," then that example is not broken.... because it works exactly how the docs tells you it will.
    References are confusingly named for historical reasons. The way they work in PHP 4 is mostly counterintuitive. And they're confusingly documented. The manual starts out with:

    Code:
    References in PHP are a means to access the same variable content by different names. They are not like C pointers; instead, they are symbol table aliases.
    This is not the case with PHP 5 object references, which are the ones that should have been called references in the first place. Except they weren't there in the first place.

    Perl has had both for years: aliases ( like PHP 4 references) and references ( like object references in PHP 5).
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  24. #24
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dreamscape
    While I agree with you that 4.4 shouldn't have broken compatibility with 4.3, I can't agree with you that because references work as advertised, they are broken
    That's cool, I can live with that
    Hello World

  25. #25
    SitePoint Wizard dreamscape's Avatar
    Join Date
    Aug 2005
    Posts
    1,080
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    >> This is not the case with PHP 5 object references

    That may well be all and good and such as well fine, but DougBTX's "broken" example was not with objects, but with normal references, and being so, is not broken. His "broken" example isn't broken, but is exactly how references in PHP work, which is what I posted and thoroughly explained why it isn't broken.

    Further, who cares what they are called as long as one understands what it is and how it works? A man in China doesn't call a mountain a "mountain" but he understands what one is.

    As long as we understand what something is within our language (PHP), it doesn't matter what it's called. They could call it "piece of doggy crap" and it would make no difference as long as we understand it ("it" being it conceptually, functionally, and practically... not "it" in name).

    We allow differences in meaning between spoken languages, but don't stand for it in other types of languages (ah hum, programming I suppose once might say is an example where this is the view taken by some)? What fun is that? How arrogant is that?

    PHP is not Java, is not Perl, is not Python, is not Ruby, is not anything but PHP. How dare anyone judge it from the viewpoint of other languages... each is beautiful in its own right.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •