SitePoint Sponsor

User Tag List

Page 1 of 3 123 LastLast
Results 1 to 25 of 72
  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
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Etnu
    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.
    I would suggest just that. It is pointless to replace a bunch of perfectly fine:
    PHP Code:
    function &foo() {
      return new 
    Klass;

    with
    PHP Code:
    function &foo() {
      
    $temp = new Klass;
      return 
    $temp;

    for a memory leak caused by how the engine chooses to handle the construct. It is the engine leaking the code, not the users PHP code. I think having PHP handle this correctly in the background is a far better solution.
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  11. #11
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,633
    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.

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

  13. #13
    SitePoint Addict
    Join Date
    May 2005
    Posts
    255
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    I would suggest just that. It is pointless to replace a bunch of perfectly fine:
    PHP Code:
    function &foo() {
      return new 
    Klass;

    with
    PHP Code:
    function &foo() {
      
    $temp = new Klass;
      return 
    $temp;

    for a memory leak caused by how the engine chooses to handle the construct. It is the engine leaking the code, not the users PHP code. I think having PHP handle this correctly in the background is a far better solution.
    Actually, I'd suggest doing away with the &foo(), install php5, and not think about it again.

    Your example could fail in any number of ways. What happens when new Klass doesn't return an object? You're trying to pass a non-existant reference. By rights, that should be a fatal error (in 5.1 RC1, it is, actually). Again, you're suggesting penalizing the entire user base for mistakes made by bad programmers. That's just silly.

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

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

  16. #16
    ********* 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
    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 are kidding right?

    Why on Earth does this...
    PHP Code:
    function &create() {
        return new 
    Thing();

    ...confuse the engine so badly it leaks memory?

    That code is perfectly normal by any stretch of the imagination and has been documented as such by the PHP community for years. Why is it bad code? Is it my duty to guess that PHP is so badly written that I should put a temp. in just in case? Uh? I had to figure this out 3 years ahead of time?

    It's a wierd (unbelievable) situation. The PHP users have to fix bugs of the PHP developers by changing their code? Since when is it my job to fix their memory leaks? How is this a "fix"?

    What else is waiting in the wings? Am I going to have to do this right now...
    PHP Code:
    $text "Hello";
    print 
    $text
    ...for when they "fix" the next memory leak in three years time?

    Is PHP development process trying to compete with Perl for the size of hole they can dig themselves in to?

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

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

  18. #18
    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 lastcraft
    Is PHP development process trying to compete with Perl for the size of hole they can dig themselves in to?
    I'm thinking 6 must be a dangerous version number. IE 6 and Netscape 6 were both dissapointments. Perl 6 has been vaporware for so long its a joke. PHP 5 is getting complaints about looking like Java, worrys that more will come in 6, and plans for more BC breaks. Java 5 just out, I read a blog today worrying that the new features were bad things taken from C++, and more worry for version 6.

    If you google "version 6 failed project", you get over 6 million results. It's got to tell you something.

    Douglas
    Hello World

  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 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 Etnu
    What happens when new Klass doesn't return an object? You're trying to pass a non-existant reference.
    It should return a reference to whatever new Klass turns out to be.

    But really, references are broke anyway:

    PHP Code:
    $a 'a';
    $b =& $a;
    $a 'b';
    $c 'c';
    $b =& $c;
    $a 'a';
            
    $this->assertEqual($b'c'); 
    I think really, the PHP crowd should just split. Those who enjoy dynamic typing should move over to Ruby or Python, and those who like the sound of type hinting can enjoy Java or C#. (You can embed Ruby in HTML much like embeding PHP in HTML. For more advanced stuff, we've got frameworks. See Rails for Ruby (great for web apps) or Django for Python (great for CMS-type apps). In Java-land they have frameworks for frameworks, so you'll be spoilt for choice, and with C# everything is spoon fed from Microsoft anyway, so you'll be happy there too.)

    The only reason to stay with PHP IMO is backwards compatability, and the monopoly-style cheap-host-market penetration PHP 4 enjoys. Breaking backwards compatability in a 4.x release (when they are talking about PHP 6!) is just rubbing salt in the wound.

    IMO,
    Douglas
    Hello World

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

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

  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
  •