SitePoint Sponsor

User Tag List

Page 1 of 3 123 LastLast
Results 1 to 25 of 54
  1. #1
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)

    Angry Enterprise ready?

    Hi...

    I just cannot believe that they really think that this should be part of the specification of the language...

    http://bugs.php.net/bug.php?id=31449

    PHP will never be Enterprise ready, or any other kind of ready, when they don't consider this a bug . Of course once the bug is marked closed (or more delightfully, bogus), you cannot coment on the ticket. You can bet I'll be commenting elsewhere .

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

  2. #2
    SitePoint Evangelist ghurtado's Avatar
    Join Date
    Sep 2003
    Location
    Wixom, Michigan
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Forgive me for playing devil's advocate. Im just trying to understand your point of view.

    In what situation is assigning "this" to a member variable useful? Does this not create a circular reference indeed? Can you do this in other languages?
    Garcia

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

    It was just the simplest example of a generic problem. Any reasonable sized application will generate objects with circular references. The visitor pattern does this for example. Also observer/event handler hiearchies are likely to do this.

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

  4. #4
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Confirms my earlier argument (another thread) that PHP lacks a lot of upfront design. A properly designed language would have taken this into account.

    PHP being "enterprise"-ready really means that Zend has sucked up to big companies enough to convince them to use PHP. It says absolutely nothing about the quality of PHP, as this bug confirms.

    Still I like PHP

  5. #5
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It seem like a trivial addition to add an IF to the comparison to check for recursion and just stop and report them as equal. But maybe it cannot be done the way it is implemented.
    Christopher

  6. #6
    SitePoint Wizard stereofrog's Avatar
    Join Date
    Apr 2004
    Location
    germany
    Posts
    4,324
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The semantics of "==" is field-by-field comparison, while "===" performs reference comparison much like java's Object.equals do. I dont think you can deeply compare recursive structures without stack overflow in any programming language.

  7. #7
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It's only a bug, so what is all the fuss about it for? All software by the definition of the word and the environment of software development will have bugs.

    No one can verify that a peice of software will ever be 100 percent free of bugs, but this doesn't mean that PHP isn't upto it in regards to large application development, far from it in fact.

    This is just making a mountain out of a mole hill in my view.

  8. #8
    Employed Again Viflux's Avatar
    Join Date
    May 2003
    Location
    London, On.
    Posts
    1,127
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think that the fact it was closed for not being a bug is the bigger problem here Dr.

    Everyone realizes and accepts that software is never free of inconsitencies or inaccuracies, but when one is pointed out and it is not addressed, or at least put on the list of things to address, it becomes a problem.

    How many other items are there that are "known" but will never be resolved?

    At my company, we routinely deploy our builds with known bugs, but we have full intention of documenting them and fixing them "somewhere" in the future. It may never happen, but at least it's documented and known as an issue.

  9. #9
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think that the fact it was closed for not being a bug is the bigger problem here Dr.
    Yer, I noticed that as well, but I don't think that PHPs status for large scale application development will be muted due to either this bug, or the point that this (and others like this) are no longer being discussed or a solution being resolved to remedy it?

    Didn't stop Microsoft dropping Windows 98 on the populus, did it

  10. #10
    get into it! bigduke's Avatar
    Join Date
    May 2004
    Location
    Australia
    Posts
    847
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    did you try this instead ?
    PHP Code:
    <?php
        
    class Recursive {
            private 
    $me;

            function 
    __construct() {
                
    $this->me = &$this;
            }
        }

        new 
    Recursive() != new Recursive();
    ?>
    I remember posting a bug regarding the use of header() imediately after setcookie(), somehow it was never resolved despite the "try this, try that" solutions. T'was kinda bugging and annoying that you do your part in notifying the dev team and they take no action.

    But this would do little in stopping giants to collaborate with Zend in pushing php up the enterprise chain. IBM's already there, SAP is in and soon Oracle will join too. For them the totality of the tool is enough rather than minor issues like these since they usually have a workaround.

    Addressing the problem noticed by Marcus, why would you want to do that anyway?

  11. #11
    ********* 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 bigduke
    Addressing the problem noticed by Marcus, why would you want to do that anyway?
    Believe me I do. This problem has now reared it's head in two separate scenarios. The first was plugging actions into observers, the second was in the context of unit testing (the mocks need to talk to a test suite and they need to be compared). I don't want the whole test suite to halt because there was a recursive comparison somewhere in the code. The code fatals in PHP 5.

    This is also the simplest version of the problem. I can trigger it with a plethora of more complicated examples, many involving basic design patterns.

    It is as much the attitude of the PHP developers that bugs me here as was pointed out. It's shoddy to dismiss a problem in the core language. Why should I work hard to promote a technology that is buggy right down to the core.

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

  12. #12
    get into it! bigduke's Avatar
    Join Date
    May 2004
    Location
    Australia
    Posts
    847
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Fatal error: Nesting level too deep - recursive dependency? in c:\apache group\apache\htdocs\test\recursive.php on line 10
    Not meaning to add to your ire, but if you lay out the logic behind it, this is something like preventing an endless while loop from working. How, in this case, would the control flow out of the infinite nest? The interpreter is probably just trying to avoid that from happening.

    Also, can you cite a real world example where this might be used? Email it to me if need be on this addy

    Edit:


    Well java supports this kind of nesting, i think, after reading this

    Probably the best way to describe this is every object knows the other ? But this is somewhat peculiar, its like each time a child is born another child is born from it uptil infinity ...

    Darn ... beats me ... i've only been 1.5 years into php

  13. #13
    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 bigduke
    Also, can you cite a real world example where this might be used? Email it to me if need be on this addy
    Testing of your basic Observer pattern:

    PHP Code:
    Mock::Generate('Observer');

    class 
    ErrorHandlerTestCase extends UnitTestCase {
        function 
    TestAttach() {
            
    $eh =& getErrorHandlerInstance();
            
    $observer1 =& new MockObserver($this);
            
    $observer1->expectOnce(
                
    'update'
                
    //,array(&$eh)); Fatal error: Nesting level too deep - recursive dependency?
                
    ,array('*'));
            
            
    $eh->attach($observer1);
            
    $eh->notify();
            
            
    $observer1->tally();
        }

    Using code:
    PHP Code:
    class Observer {
        function 
    update() {
            die(
    'abstract method');
        }
    }

    class 
    ErrorHandler {
        var 
    $_observers=array();
        var 
    $_error_info;
        function 
    attach(&$observer) {
            
    $this->_observers[] =& $observer;
        }
        function 
    detach(&$observer) {
            foreach(
    array_keys($this->_observers) as $key) {
                if (
    $this->_observers[$key] === $observer) {
                    unset(
    $this->_observers[$key]);
                    return;
                }
            }
        }
        function 
    notify() {
            foreach(
    array_keys($this->_observers) as $key) {
                
    $observer =& $this->_observers[$key];
                
    $observer->update($this);
            }
        }
        function 
    getState() {
            return 
    $this->_error_info;
        }
        function 
    setState($info) {
            
    $this->_error_info $info;
            
    $this->notify();
        }
    }

    //implement singleton via function
    function &getErrorHandlerInstance() {
        static 
    $instance = array();
        if (!
    $instance$instance[0] =& new ErrorHandler();
        return 
    $instance[0];

    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  14. #14
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have had problems with this in the real world, when unit testing. I can't remember the details now. It does shake your confidence in php a little.

  15. #15
    SitePoint Evangelist ghurtado's Avatar
    Join Date
    Sep 2003
    Location
    Wixom, Michigan
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Just for the sake of comparison, the following works in ruby:
    PHP Code:
      class Recursive 
          
    @me

          def initialize
    ()
              @
    me self
          end
      end

      
    if(Recursive.new == Recursive.new)
        print 
    "they are the same";
      else 
        print 
    "they are different";
      
    end 
    Ruby, which compares objects by checking whether the memory reference to them is the same, tells us that they are different objects. I believe this to be the correct approach, since two objects are not truly the same (even when they are of the same class and have the same properties) unless they occupy the same memory space.

    I am a Ruby newb, so maybe someone can tell me if there is an operator to compare objects in Ruby "apples to apples" and how this should be implemented in PHP.
    Garcia

  16. #16
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hah, bogus. Surely something as innocuous as a equality test shouldnt cause a problem.

    I dont think PHP has a language spec. This is possibly part of the problem. It doesnt seem to have ever been designed (ok it may have been at some ancient version) but its organic growth has created all sorts of little(?) gotchas that catch everyone out.

    HTTP streams bit me the other week, expecting atleast HTTP compliance, where all 2xx status codes should be considered successful, only 200 is in PHP. Response I got is a stream context option "may" be added... at some point.

  17. #17
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Let's all just switch to Python.

  18. #18
    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 BerislavLopac
    Let's all just switch to Python.
    Or maybe just keep using PHP but pretend there are no rough edges?!?

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

    Or just compain loudly and shame the developers into implementing a fix. Consumer power and all that. Actually the language is free, but we get stung for accelerator licenses. I bet it would be fixed if it were an accelerator bug. Perhaps if I make use of that channel...

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

  20. #20
    SitePoint Wizard stereofrog's Avatar
    Join Date
    Apr 2004
    Location
    germany
    Posts
    4,324
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ghurtado
    I am a Ruby newb, so maybe someone can tell me if there is an operator to compare objects in Ruby "apples to apples" and how this should be implemented in PHP.
    Like java, ruby has no built-in deep comparison. If you need it, you should override "==". Default Object#== is defined as Object#equals? which means "identical" i.e the same object.

    IMHO, the cause of the whole confusion is that php offers deep comparison by default while other languages dont even implement it, because no one really needs it.

    Quote Originally Posted by lastcraft
    Or just compain loudly and shame the developers into implementing a fix. Consumer power and all that. Actually the language is free, but we get stung for accelerator licenses. I bet it would be fixed if it were an accelerator bug.
    As php guy already told you, this is not a bug and is "by design". Face it, such "design" is pretty ugly, but it's another story...

  21. #21
    SitePoint Zealot
    Join Date
    Jun 2003
    Location
    Elsewhere
    Posts
    107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    It's only a bug, so what is all the fuss about it for?
    What fuss? It's a BUG. It needs to be FIXED. There are no 'only bugs'.

    Quote Originally Posted by Dr Livingston
    No one can verify that a peice of software will ever be 100 percent free of bugs, but this doesn't mean that PHP isn't upto it in regards to large application development, far from it in fact.
    This isn't about software (PHP) having bugs, it's about the reaction of the developers towards submitted bugs.

    @Marcus: I know how you feel. I was recently involved in a discussion about a 'bug' in php_check_syntax. In the end, the entire function was removed, even though most users agreed that it really had some value but did more than it should (it semi-included the specified file as well). On several occasions I've been utterly amazed by the decisions and replies made by the PHP developers... some of them made absolutely no sense at all.

    I still love PHP5 though.

  22. #22
    SitePoint Guru Galo's Avatar
    Join Date
    May 2005
    Location
    Holland!
    Posts
    852
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Sorry but everyone who has a little experience in PHP knows that this gives a fatal error no ?

    <?php
    class Recursive {
    private $me;

    function __construct() {
    $this->me = $this;
    }
    }

    new Recursive() != new Recursive();
    ?>

    is just silly code...
    $this->me = self(); would actualy work in abstract evironments so it is posible...

    and tmho, PHP is enterprise ready, it's only not Client-Enterprise but Server-Enterprise, a lot of difference...
    Business as usual is off the menu folks, ...

  23. #23
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It would probably be good if Marcus posted some code where the functionality would be useful. He mentioned it in the php.net post...that Visitors and Observers sometimes need it.

    *points to Marcus*

  24. #24
    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 stereofrog
    IMHO, the cause of the whole confusion is that php offers deep comparison by default while other languages dont even implement it, because no one really needs it.
    I agree on that. When using the comparator-operator on non-scalars, PHP should rather compare if two references point to the same memory-address than trying to compare by value.

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

    With respect this issue is far more serious than a casual commentry would demonstrate. Not just the flaws that must exist in the language engine if this can get through, but the attitude of the core devlopers to their own code.

    Quote Originally Posted by stereofrog
    As php guy already told you, this is not a bug and is "by design". Face it, such "design" is pretty ugly, but it's another story...
    No, this is a gap in the design. If they removed the == operator and implemented overloading instead, that would be bug free. It's especially punishing if you are trying to write PHP4 compatible code.

    In SimpleTest I wrote assertIdentiacl() to do the comparison recursivelyin PHP. That's slow to run, but it's a dozen lines of code. It wouldn't be much to move that dozen lines of code into the PHP engine itself and make it safe. Alternately they could make the the serialize() function produce canonical output so that I could use that, but taht's another fun story.

    Anyway, you misunderstand the problem. The fix is simple, but the PHP devs could not even be bothered (and you cannot reopen a ticket).

    Suppose you are writing a filter chain and you do a comparison of an action to make sure you are not in a loop. You actions are value objects, right. Except that someone may write one in the future that keeps a refernce to a shared object. That's a time bomb. Somewhen down the line your working comparison will cause a server crash. Do you really want to document that an action may never ever have a reference to a shared object. We were attaching an observer to the actions to generate an error message. I don't need to write thirty odd lines of code to explain this in detail do I? You see the implications right?

    The other problem Jason has already posted an example of. You try to compare the mock you sent into a sytem with the one that came out (or do a test in the code internally). The mocks currently need a link back to the test suite to be PHP4 compatible (in PHP5 I can throw exceptions instead). Any mock comparison used to throw a fatal. I have added a bit of hacky eval() code to get around this for now, so that at least the tester itself doesn't break.

    These scenarios have already happened to me. They will happen to any autheor of a remotely complicated, or "enterprise", system. Any time you use the == operator on parameters suplied to your library by someone else, your code is capable of throwing a fatal. Think about it. You have no way of demonstrating that your code will complete everytime you use the == operator. You say that's not a bug?

    I'll stick my neck out here and give my definition of what I think is a bug: "Fundamental language constructs should not throw fatals". Hardly radical, is it?

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


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
  •