SitePoint Sponsor

User Tag List

Results 1 to 18 of 18
  1. #1
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Php5 Bugs And Bad Design

    Take a look at the following code. If you implement 2 interfaces that share the same function name, PHP will issue a FATAL ERROR and in an older version it just froze.

    The error: Can't inherit abstract function SecondInterface::execute()

    How the hell could they do that ? The term is not inherited, the term is implemented. An interface is not an inherited class, it is a contract, and the only big answer to why multiple inheritance is bad was just this. Interfaces were introduced to solve such errors, not to issue fatal errors !!! )(&*(^&*&WHFGV87

    BTW: I know for a fact that the example bellow should have worked (in Java or in any other language that have interfaces - it does).

    PHP Code:
        interface FirstInterface
        
    {
            function 
    execute();
        }
        
        interface 
    SecondInterface
        
    {
            function 
    execute();
        }
        
        class 
    MyClass implements FirstInterfaceSecondInterface 
        
    {
            function 
    execute()
            {
                echo 
    "Hello World";
            }
        }
        
        
    $obj = new MyClass();
        
    $obj->execute(); 
    My oppinion is that, internally, iterfaces are just abstract classes for PHP.

  2. #2
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    And classes are arrays with knobs on!

    Duck typing is supported in PHP, so I say use that rather than explicit interfaces/abstract classes/type hints/etc.

    Douglas
    Hello World

  3. #3
    Resident Java Hater
    Join Date
    Jul 2004
    Location
    Gerodieville Central, UK
    Posts
    446
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Can you see why I was ranting so much against PHP in the other thread about PHP 4.4 and 5.1.0.b2. It's the constant repeation of running to *stupid* language level bugs like this that is making people move to other languages like Marcus said. What doesn't help is the way Zend try to deny the bugs, or take so long to fix them.

    Again with bug #33643, which I reported at the beginning of the week, the first reply I got from Zend was the stupid

    Thank you for taking the time to write to us, but this is not
    a bug. Please double-check the documentation available at
    http://www.php.net/manual/ and the instructions on how to report
    a bug at http://bugs.php.net/how-to-report.php
    message with no reasoning why my bug report was not bug. I had to reopen the bug and tell them that they were giving me a load of BS coz there was no mention of it in the documentation.

    They later reopened the bug as a documentation bug. Anotherwords, they don't want to admit to the fact it's a bug, so they take the easy option of telling people to work round their screw up.

    After a load of banter on the internals list, they've finally faced up that the bug is a scripting engine bug, which is what I originally reported the bug as. It's taken 3 status changes for them to come to the conclusion to agree with what I originally opened the bug as.

  4. #4
    Resident Java Hater
    Join Date
    Jul 2004
    Location
    Gerodieville Central, UK
    Posts
    446
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    FYI, reported the bug under http://bugs.php.net/bug.php?id=33698

    I enjoy filling bugs to Zend. It gives the 'cowboy C coders that got lucky' something to do in their spare time when they aren't bodging up "features" like magic quotes I got a about 15 other bugs filled under another email address :P

  5. #5
    SitePoint Evangelist jplush76's Avatar
    Join Date
    Nov 2003
    Location
    Los Angeles, CA
    Posts
    460
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    miiJay, zend doesn't own PHP... most people contribute to the codebase for free. If you dont like something open the source code and fix it.
    My-Bic - Easiest AJAX/PHP Framework Around
    Now Debug PHP scripts with Firebug!

  6. #6
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jplush76
    miiJay, zend doesn't own PHP... most people contribute to the codebase for free. If you dont like something open the source code and fix it.
    You are wrong. The community contributes to PECL modules and eventually, if a module is good enough, becomes part of PHP. But to modify PHP's core, you have to be a Zend employee, or fork the PHP distro. And nobody is going to use your fork.

  7. #7
    Resident Java Hater
    Join Date
    Jul 2004
    Location
    Gerodieville Central, UK
    Posts
    446
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jplush76
    miiJay, zend doesn't own PHP... most people contribute to the codebase for free. If you dont like something open the source code and fix it.
    That's not quite how I see it. Zend do *MOST* of the development on PHP, and the odd people here and there contribute patches from outside Zend. If I could, i would submit fixes. However the C code for PHP is too messy and tricky for your average coder to understand

  8. #8
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by bonefry
    You are wrong. The community contributes to PECL modules and eventually, if a module is good enough, becomes part of PHP. But to modify PHP's core, you have to be a Zend employee, or fork the PHP distro. And nobody is going to use your fork.
    Unless I completely misunderstood you, I don't think that is correct. A patch to the core has to be accepted by the PHP Group to be accepted into the engine. No more, no less. The PHP Group holds the copyright on the codebase and from what I can tell, also provides governance over related issues such as the website, documentation, releases, etc.

    Of course, Zend employees make up a good portion of the membership but unless I am mistaken not the entire membership. If someone with more knowledge could clarify, that might help.

  9. #9
    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)
    There are quite a number of people not employed by Zend who are in the PHP Group and review and apply patches. In particular, Derick Rethans is currently the "release master" for the 4.4 branch.
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  10. #10
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    OK, I don't know what's the deal with the PHP Group, but it's not that easy to contribute to the core. Maybe at some point I'll remember C++ and actually try to contribute, but open-source doesn't not mean "if something is broke, fix it yourself because we don't care". And this kind of publicity is bad for companies. They are not all hackers you know.

  11. #11
    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 jayboots
    The PHP Group holds the copyright on the codebase and from what I can tell, also provides governance over related issues such as the website, documentation, releases, etc.
    Zend Engine is (c) Zend, not PHP Group.

    AFAIK fatals can only be thrown by ZE code, so if you have a fatal, it's a Zend problem.

  12. #12
    Resident Java Hater
    Join Date
    Jul 2004
    Location
    Gerodieville Central, UK
    Posts
    446
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    So you know, this bug was marked as bogus. I think if they are going to keep this behaviour it should be documented as people won't expect this behavior because it doens't follow the 'policy of least suprise'. Anyway, it's not a major issue, as it can be easily be worked round, and it doesn't break anything.

  13. #13
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Anyway, about bug http://bugs.php.net/bug.php?id=33698 - I think that behaviour was intended because they want to pass object by reference in PHP5, and $this it's a pseudo-variable. That means it's not real. And $b = $this works.

  14. #14
    Resident Java Hater
    Join Date
    Jul 2004
    Location
    Gerodieville Central, UK
    Posts
    446
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by bonefry
    Anyway, about bug http://bugs.php.net/bug.php?id=33698 - I think that behaviour was intended because they want to pass object by reference in PHP5, and $this it's a pseudo-variable. That means it's not real. And $b = $this works.
    Yea, I realise that, and I have no problem it...

    however due to the bad reference implementation nn PHP4, code quite often needs things like ..

    $b =& $this;

    in fact it is used quite often when dealing with trees of objects that use recursion to step through the parent nodes. I know the WACT template compiler uses the technique, as do I in my code.

    Of course in PHP5, you don't need the &, however omitting the & breaks PHP4 code. This is where Zend have done a repeat offense of breaking backward compatiblity in a careless and unplanned manner.

    Anyway, the fact is this breaks code, and regardless of the situation of is this "intended behavoir" or not, this is a language querk and it should be documented if they are doing something that breaks code

  15. #15
    SitePoint Evangelist jplush76's Avatar
    Join Date
    Nov 2003
    Location
    Los Angeles, CA
    Posts
    460
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by bonefry
    OK, I don't know what's the deal with the PHP Group, but it's not that easy to contribute to the core. Maybe at some point I'll remember C++ and actually try to contribute, but open-source doesn't not mean "if something is broke, fix it yourself because we don't care". And this kind of publicity is bad for companies. They are not all hackers you know.

    do you think its easy to contribute to the linux core?
    open source exactly means "if something is broke, fix it yourself". Not because no one cares but because you can. If you find a bug in C# good luck getting it fixed. You find a bug in php, a week later its fixed and released from what I've experienced. Every thread you're in you are *****ing about something.
    My-Bic - Easiest AJAX/PHP Framework Around
    Now Debug PHP scripts with Firebug!

  16. #16
    Resident Java Hater
    Join Date
    Jul 2004
    Location
    Gerodieville Central, UK
    Posts
    446
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jplush76
    You find a bug in php, a week later its fixed and released from what I've experienced. Every thread you're in you are *****ing about something.
    Well my experience is different. Bugs are fixed in a week if Zend can find a quick fix. However most engine level bugs reported seem to never get fixed, or get fixed several months down the line. Look at things like bug 8130, that didn't get fixed until last year I think. Again, they never fixed http://bugs.php.net/bug.php?id=31449, again they only just fixed http://bugs.php.net/bug.php?id=32963 / http://bugs.php.net/bug.php?id=20953, at that was at the cost of breaking backward compatiblity, http://bugs.php.net/bug.php?id=32983 still is not fixed.

    It's not directly Zends fault. It's more of an issue that PHP has had no formal design as a language, so all of the inconsistentcies are now making it very hard to maintain without breaking some form of backward compatiblity.

    After http://bugs.php.net/bug.php?id=33698 was marked as bogus, I reopened it as a documentation bug, and wez later came along and then marked it as Feature/Change Request, and suspended it. In this case Wez openly admits there are engine level issues that really need to be addressed in the long term. The fact that Wez has admitted this is not possible to fix easily proves my point that PHP's lack of design is now catching up with them and leaving them with a string of hard to fix bugs that often end up having to compromise backward compatiblity in some cases. In fact in http://bugs.php.net/bug.php?id=33643 dmitry has even said they will probably have to break backward compatiblity yet again!!! The continuous breaking of backward compatiblity in many releases of PHP really is not doing PHP or Zend no favours for expereienced coders who have to keep changing their code. Come on, we are on PHP 4.4 and we are still breaking backward compatiblity.

    Surely after 4 major revesions of the PHP4 branch and counless revision level releases, you would think things would stablise ?!?!?!?!? PHP 4 has been plauged with security updates and breakages like the move to remove globals, and a broken SQL injection protection mechanism which have been phased in well after the initial 4.0.0 release

    I know I'm probably not helping by slagging of PHP as much as I have, but you can't deny PHP and/or Zend really need to sort themselves out if people are to continue using PHP in large scale environments.

  17. #17
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I know I'm probably not helping by slagging of PHP as much as I have,
    Nope, your not

    but you can't deny PHP and/or Zend really need to sort themselves out if people are to continue using PHP in large scale environments.
    Yes, they do, and I would think they would need to hurry up about it as well? But what is really funny is that despite all the script that I've written, I've never really had a problem with PHP5.0.1, PHP5.0.3 on Windows.

    Funny, it's like people are going out their way to create situations where bugs are more or less, apparent? But anyways, I don't really see a problem, if there is one, then you work around it, don't you?

    Isn't that what development is all about? All systems are prone to bugs and mishaps, it's just life.

  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 Dr Livingston
    Isn't that what development is all about? All systems are prone to bugs and mishaps, it's just life.
    A bug you lovingly hand insert into code is much different than having the semantics of the language shift out from underneath you. Some things you need to count on.
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.


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
  •