Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
PHP Programming Technology

PHP 5 OO In 24 Slides 56

Posted by timothy from the comprehensible dept.
An anonymous reader writes "At php|works about a week ago John Coggeshall gave an interesting talk on object oriented programming using PHP version 5. Even if you couldn't be at the talk, his slides are available online which gives you a pretty good idea of what you can expect from the OO model. Java programmers will be pleased."
This discussion has been archived. No new comments can be posted.

PHP 5 OO In 24 Slides More

PHP 5 OO In 24 Slides

Comments Filter:

  • Error on slide 5 (Score:2, Informative)

    by Anonymous Coward
    From slide 5:

    Member methods may also be declared final, preventing them specifically from being overloaded in a sub class

    s/overloaded/overridden/

    See here [planetmirror.com].
    • I'm not an OOP expert, but I've always thought that the ability of having two or more methods with the same name was called overloading (I did learn that from some C++'s manuals/help files)

      That URL says override but it's just a point of view, the real name is method overloading. AFAIK.

      google "php method overloading [google.com]" returns 35,000 links.
      google "php method overriding [google.com]" returns 16,000 links

      • Re:Error on slide 5 (Score:3, Informative)

        by Smallpond ( 221300 )
        I think AC is correct:

        PHP 5 introduces the "final" [php.net] keyword to declare final members and methods. Methods and members declared final cannot be overridden by sub-classes.

        overload [php.net] has a specific meaning.
      • All your Googling shows is that one is discussed more often than the other. Also, it could also be that the public-at-large missuses a technical term. Sorry but you haven't proven anything.
  • I'd like to hear more about who designed the OO features of PHP 4, and who (re)designed them for PHP 5.

    As many times as I've heard this fun fact, it never ceases to amaze me: "In ZE / PHP 4 objects weren't references, so when they were passed to a function a copy was made."

    I've never heard this one before, and it's just as ridiculous: "In PHP 4, you couldn't access a member function or properity indirectly through another object's member function or properity.."

    Yikes. How did they get it that wrong!?

    • PHP4's OO features were pretty much a late cycle hack. PHP5's OO was thought out early and carefully designed.

      If anything, the fact that PHP4's OO features worked as well as they did was impressive. The fact that they were limited was due to the point at which they were implemented. If anything, it illustrates the need to plan features early in the development cycle.

      --
      Evan

    • Re:history of PHP OO? (Score:4, Informative)

      by kris ( 824 ) <kris-slashdot@koehntopp.de> on Thursday September 30, 2004 @03:41AM (#10392187) Homepage
      I'd like to hear more about who designed the OO features of PHP 4, and who (re)designed them for PHP 5.

      PHP 3 was a procedural language and designed as such. Rasmus made it that way, and when you look at the code for php.net, or other code Rasmus made or approved, you'll see that he has a case and a reason for all this.

      PHP 3 had so called classes and objects, which were just a fancy syntax for hashes of values and functions, added as a midnight hack by Zeev and Andi to the language. Also, that hack was severely buggy. I ought to know, because I tried to use it in implementing PHPLIB at that time, and filed over 60 bug reports against PHP 3 during the six release candidates for it.

      PHP 4 tried to extend PHP 3's object capabilities, but that extension was driven mostly by Zeev, who admittedly had little knowledge of or interest in OO. Also, he tried to model PHP 4's OO capabilities with the image of C++ in mind. During the PHP 4 lifecycle, I tried several times to nudge Zeev and the PHP community into the direction of Smalltalk and Objective-C, which provide an object model that is much better suited to a scripting language than C++'s model, and also is much more expressive, but my efforts were late and since I decided not to code to the Zend engine itself, somewhat fruitless.

      Zend, especially Zeev, did do his homework for the version 5 release, though, and redesigned all things OO from ground up. He did so in front of a backdrop of PHP being used more and more in off-web usecases, that is, PHP 4 slowly becoming a mainstream language leaving its little specialized corner of web applications. Zeev's idea was to provide the version 5 release of the capabilities that are needed for PHP to become a real scripting language that can be used in larger projects, without breaking to much backward compatibility, and with keeping the dynamic "scripting" capabilities and feel of the language.

      He succeeded superbly - PHP 5 provides the OO you need, and enables you to operate more within the mindset of a Smalltalk or Objective-C programmer than within the mindset of a Simular or C++ programmer. In PHP 5, objects are dynamically typed (class is a property of the object, not a property of the variable name), completely self-descriptive, and capable of delegation, emulation and posing.

      Try it out and do not let the syntax deceive you - this is not a C++ or Java like language, try Smalltalk and ObjC for size.
      • That was awesome, thanks!

        Except for the interfaces and final features, PHP 5 OO looks a lot like that of Ruby (or Python, but more Ruby). Am I right? And I don't know what you mean by "delegation, emulation, posing". (Although I'm guessing _get, _set, and _call have to do with at least one of them.)

        I don't have a problem with non-OO languages; I'm not an OO purist. But I do think if you're going to add support for a programming paradigm to your language, you should not design it in such a way that it

        • I know neither Ruby nor Python, so I can't tell.

          And I don't know what you mean by "delegation, emulation, posing". (Although I'm guessing _get, _set, and _call have to do with at least one of them.)

          Delegation is a mechanism in the Objective-C Toolkit AppKit as it was sold with NeXTstep. It allows you to set a delegate object for any object. Method calls that cannot be handled by an object with a delegate have a chance to be handled by the delegate instead of the original object before a runtime error i
          • So if Java is a consultant from IBM with suit and tie, and Python is an academic from the cs languages dept a european university, PHP is wearing an overall with oil stains on it and it has dirt in the face, but it somehow gets the job done.

            That is exactly what I always suspected was the case with PHP, but I've never been able to get a serious PHP programmer to confirm it. Thanks.

            A little off the subject, but, I don't think Python is an academic kind of language at all; if anything I feel like it's a le

  • If you bother to make slides for a presentation, and then publish them on the web, you should take the extra minute or two and run a spell check over them. Reading something that includes misspellings and grammatical errors every other sentence is not just distracting -- it makes me wonder if the content and examples are correct.
  • Java programmers will be pleased.

    Personally, I'm less than impressed. Why should I cheer and hooray about PHP introducing some OO features in PHP in 2004 almost all of which Java has had since version 1.0 in 1995? Is that supposed to be a great feat?!

    • Java was designed to be an OO language. PHP was not.

      Personally, I'm not impressed for other reasons. OO is severely overrated- its a good solution for some problems, its a bad one for others. It is not the holy grail, and its not meant for use on every project. I don't see it as being truely useful for a web scripting language.
  • Does it make sense to define classes, create objects, restore objects from some serialized storage or database, etc. etc. in the context of a web application? That's a lot of scaffolding to build and tear down for every HTTP request.

    OOP clearly makes sense in many applications where the class definitions and objects have a lifetime longer than a single call. And it's possible to write server-side applications that "live" longer than a single HTTP request. But that isn't the PHP execution model.

    The ZEND Ac

    • Re:Does OOP make sense for web scripting? (Score:1, Insightful)

      by Anonymous Coward

      Does it make sense to define classes, create objects, restore objects from some serialized storage or database, etc. etc. in the context of a web application? That's a lot of scaffolding to build and tear down for every HTTP request.

      Yes, it does make sense. OO is a way to abstract your code and make it easier to test and re-use.

      What do you mean "scaffolding"? Do you have some numbers? Benchmarks? Before/after comparisons? Creating an object is (supposed to be) a lightweight event. You probably use fun

      • Thanks for the thoughtful reply. My question was "Does OOP make sense for web scripting." You answered a different question, something like "Explain what OOP is for."

        I don't have any problem understanding OOP, thank you -- I've been programming for a long time and learned OOP in Smalltalk and C++ back when they were new.

        I'm not asking whether OOP is a worthwhile technique or not. I'm asking if it makes sense, in general, for web applications, where class definitions and object instantiations and initializ
        • you said:
          "I'm asking if it makes sense, in general, for web applications, where class definitions and object instantiations and initializations are done to handle a single HTTP request."

          yes or no depending on how you look at it :)

          lots of times it doesn't boil down to a single HTTP request. there are lots of web applications that span multiple pages (HTTP requests) and use the $_SESSION for persistence.

          i don't think that PHP 5 is really emphasizing OO as much as making sure it's apparent to everyone.
    • That's a lot of scaffolding to build and tear down for every HTTP request.

      It is, and overdone OO framework is what makes PHP web applications slow. The faster PHP applications only use a limited amount of OO, and like you did, as a namespace management tool.

      But PHP 5 is a base for more than mere web applications. The version 5 update readies PHP to leave the web application scope and makes it a fully blown scripting language. PHP is already being used in this context, albeit not yet fully recognized - mo

      • But PHP 5 is a base for more than mere web applications. The version 5 update readies PHP to leave the web application scope and makes it a fully blown scripting language. PHP is already being used in this context, albeit not yet fully recognized - most people still associate PHP with the web, like you did.

        I know that PHP 5 is being positioned as more than a web language. I doubt it will succeed there. That space is well-served by more mature and better thought-out dynamic languages such as Perl and Pyth

        • I know that PHP 5 is being positioned as more than a web language. I doubt it will succeed there.

          For many people, earlier versions of PHP have been their first programming language. Wait to see them grow up - PHP grows with them.

          • For many people, earlier versions of PHP have been their first programming language.

            I don't know which crowd of young programmers I'm more worried about -- those who learned PHP as their first language, or those who learned Java. I've mopped up enough amateur PHP (and ASP/VBScript) projects in the last few years. It's a flashback to the days when people learned some simple home computer BASIC and then got a job in corporate IT. Not necessarily bad, but you sure can learn a lot of bad habits, and fail to

    • Let me add an example of what I'm getting at. Is this:

      $db = mysql_connect('server', 'user', 'password');
      mysql_select_db('foo', $db);
      $rs = mysql_query('SELECT name,age FROM people');

      while ($row = mysql_fetch_assoc($rs)) {
      echo $row['name'] . ' : ';
      echo $row['age'] . '<br>';
      }

      Somehow worse or less preferable than this:

      require_once 'DB.php';
      ...
      $db =& DB::connect('mysql://user:pw@host/foo');
      $db->set FetchMode(DB_FETCHMODE_ASSOC);
      $rs =& $db->query('SELECT name,age FROM people');

      whil

    • Does it make sense to define classes, create objects, restore objects from some serialized storage or database, etc. etc. in the context of a web application? That's a lot of scaffolding to build and tear down for every HTTP request.

      Java and C# are both object oriented languages and have hugely successful related web development platforms (J2EE and .NET), so what was that point again? :)
  • Java programmers will be pleased.

    I'll be pleased when PHP gets static typing.

    • I'll be pleased when PHP gets static typing.

      Why? If you want that just use Java.

      Adding more and more Java-like features to PHP is going down the wrong path. Web programmers took to PHP enthusiastically because the language is simple, the libraries are extensive (if not always robust), and you can get something working fairly fast.

      If PHP continues to bloat with OOP and exceptions and perhaps static typing, it will lose its advantage and appeal. If PHP morphs into a kind of patchwork Java -- with all o

  • A much more better speled deskripshun of PHP5's OO language enhancements are is available from the horse's mouth [zend.com]
  • Yes, Java developers will be pleased... because they'll stick with Java. PHP is destroying its niche by trying to go the Java-ish OO route.

Slashdot Top Deals

Garbage In -- Gospel Out.

Close