Slashdot Mirror

← Back to Stories (view on slashdot.org)

PHP 4.3.0 w/ZEND 2 Alpha

Posted by timothy on from the folding-things-in dept.

Twintop writes: "PHP.net has released the a new version of PHP 4 to include the new Zend 2 Scripting Engine. This alpha update adds more increased support for Java and .NET technologies. More can be found on PHP.net and Beta News.com."

32 comments

  1. Stability by mirabilos · · Score: 1

    I wonder whether this is really quality-checked,
    and I guess, not.
    Oh boy, we need a split "stable"/"testing" for
    PHP on the BSD ports tree...

    --
    My Karma isn't excellent, damn it! (And /. still does not get UTF-8 right in 2012. Wow.)
    1. Re:Stability by Anonymous Coward · · Score: 1, Funny

      No you don't, because *BSD is dying.

  2. PHP has finally made it... by metacosm · · Score: 4, Interesting

    Long ago, I used php on a very small project, and it worked wonderfully (due to the utter simplicity of the project).

    Since then, I have not touched it, due to immature error handling, terrible objects and inconsistancies between functions and methods.

    It seems that this version (based on the Code Samples) has fixed most everything I once hated, and that I might get to use php in a production enviroment sometime soon.

    Most important things to me are try/catch and destructors.

    1. Re:PHP has finally made it... by RAMMS+EIN · · Score: 1

      So let me get this striaght...what you are saying is that you hated PHP because it didn't have exception handling and destructors? That makes the languages that you don't hate pretty rare I'd say... I personally have never had any need for exceptions or OOP for generating my webpages, and I don't have the feeling they're lacking in any aspect. Neither do the people who hire me.

      I really don't see what your problem with PHP is. If there's anything wrong with it it might be bloat, but with the small footprint and fast execution PHP has that really doesn't seem a legitimate complaint to me. I have loved PHP ever since I started using it.

      Also, contrary to what others have said, PHP 4.2.0 works fine with Apache 2.0.35, at least on my box.

      --
      Please correct me if I got my facts wrong.
  3. So misguided by andy@petdance.com · · Score: 4, Interesting
    I'm so frustrated by the culture of performance:
    Private Members.
    The Zend Engine 2.0 introduces private member variables. Note that for performance reasons no error message is emitted in case of an illegal access to a private member variable.
    "For performance reasons", they're ignoring the encapsulation that would help correctness...
    1. Re:So misguided by zangdesign · · Score: 2

      Well, when you consider that PHP is primarily used as a scripting language on web servers, it makes sense to optimize for performance. You can't have processes hanging around too long, else they start to clog things up and pretty soon you have a really lovely rackmounted paperweight.

      Performance is everything for web servers. Get 'em in, get 'em out, next please.

      --
      To celebrate the occasion of my 1000th post, I will post no more forever on Slashdot. Goodbye.
    2. Re:So misguided by baturkey · · Score: 1

      How is it ignoring the encapsulation? The value of the private variable is not returned. All this affects is ease of debugging.

    3. Re:So misguided by andy@petdance.com · · Score: 5, Informative
      Well, when you consider that PHP is primarily used as a scripting language on web servers, it makes sense to optimize for performance. You can't have processes hanging around too long, else they start to clog things up and pretty soon you have a really lovely rackmounted paperweight.

      And that's what happens now if you do any amount of use of classes. Unless you buy the Zend Optimizer, anything that uses classes requires tons of recompilation of the PHP code for each page. We found that we were spending 20% of real response time just recompiling the class files for each page.

      This performance tweak is just a drop in the bucket compared to that.

    4. Re:So misguided by andy@petdance.com · · Score: 2
      All this affects is ease of debugging.

      That's pretty huge in my book. PHP already doesn't support any sort of accessing of the callback stack (although I see it's in the new one), much less interactive debugging.

      The lack of debugging facilities is the #1 reason why I and my department are getting away from PHP.

    5. Re:So misguided by cymen · · Score: 3, Informative

      Have you tried the open source PHP optimizer APC:

      http://apc.communityconnect.com/

    6. Re:So misguided by BusDriver · · Score: 2, Informative
      Try using this fantastic PHP tool.
      Just as fast as Zend Accelerator, costs exactly nothing.

      The PHP Accelerator.

    7. Re:So misguided by kix · · Score: 1

      PHP does support interactive debugging - zend has their IDE and there are several free ones as well - you just need to install a small component to the server and you can do remote step-by-step debugging or you can run the thing locally or however you want to.

      --
      I am SO cool I can keep meat fresh for a WEEK!!!!
    8. Re:So misguided by phpa · · Score: 1

      The ZO is actually free, ZA costs money. But, and as others have said, if you use PHPA then you'll get your performance back + a little more because I put an optimiser into PHPA as well. It's also free. Concerning the 20% cost, you were lucky, that's not too bad. Sites can experience even bigger overheads, and is why using an accelerator can make a huge difference. Some folks using Smarty reported nearly a 10 times speed improvement, so there are definitely things you can do to get back precious CPU cycles whilst enjoying the benefits of PHP.

    9. Re:So misguided by Lordrashmi · · Score: 1

      There are plenty of ways to debug PHP. I have never had a problem finding out where the problem is happening.

      Out of all the languages I have used for web based developement (PHP, PERL, VB *shudder* and JSP) PHP has been the quickest to develop and easiest to maintain. Also, given proper coding techniques and server configuration, the fastest performer of the group.

      These were not just small projects either, my current job has huge projects we are doing in PHP.

      So just curious, what language are you doing to?

    10. Re:So misguided by Electrum · · Score: 2

      I'm so frustrated by the culture of performance

      I agree completely. The PHP developers seem very misguided. They refuse to fix many bugs in the name of "performance". Things like infinite recursion crashing the interpreter. At the very least, they could include a debug version, which would run slower, but help developers find errors. Things like the new private member variables silently erroring is NOT acceptable behavior for a scripting language, especially one that claims to be easy to use.

      PHP already has enough bugs that make it hard to use, especially for those not experienced with it. It's really fun when a syntax error causes the parser to indicate that the error is hundreds of lines away from where it really is, or even in a separate file. Adding MORE bugs of this kind in the name of "performance" does not help to make PHP more professional. I really like PHP, and have been using in commercial environments for more than two and a half years, but these types of things are making me seriously consider switching to Python.

  4. Commercial addons restricting by Anonymous Coward · · Score: 2, Insightful
    It was often said that the developers could have addon products to GPL software and that's how you could make money. With PHP+ZEND, and other GPL software that has proprietary offshoots, it's really proven to me that this is no good thing. The GPL software is pigeonholed in its current role, and more often than not it will never go on to fill the role of the addon software.

    It's not out of dislike for commercial software - it's because PHP is a scripting engine, and their addon Zend optimiser isn't. It's not that there aren't open source replacements but they'll never become part of the base PHP.net distro. This affects the quality of the software.

    Is there anything that can be done about this? Especially for other new projects that don't want to let social issues affect the quality of their software.

    1. Re:Commercial addons restricting by Anonymous Coward · · Score: 0

      "it's not that there aren't open-source replacements"

      uhm, from php-accelerators FAQ:

      Q. Can I download the source?

      A. The source is not currently available for download but may be released in the future. I like to release 'ready-to-go' versions as it's simpler for users and there's no need to fiddle with compilers etc.

      just exactly how is that open-source?

    2. Re:Commercial addons restricting by phpa · · Score: 1

      The poster simply made a typo. For various reasons I decided to not make PHPA OpenSource, but the point is that it's free and works very well. OpenSource isn't all it's cracked up to be, particularly when the code you download doens't compile. E.g. APC, that I never managed to get to compile. I think that people need to get out of the mindset that they have a right to source code and intellectual property just because a product is made freely available. Of course by not widely releasing the source the number of platforms are restricted, but I willingly shoulder the burden to ensure that the main ones are usually covered. For folks that really need the source an NDA can be signed, and one of the internets largest sites has just done that very thing, and then you've got it.

    3. Re:Commercial addons restricting by King+of+the+World · · Score: 1

      >The poster simply made a typo.

      No I didn't. I was under the mistaken impression. Interesting story though - thanks. Did they want the source because of their platform, or to modify, or what?

      --
      --Giving to trolls for the benefit of us all
    4. Re:Commercial addons restricting by phpa · · Score: 1

      > No I didn't. I was under the mistaken > impression. I was being generous ;) > Interesting story though - thanks. > Did they want the source because of their > platform, or to modify, or what? It just better suited their business approach. They put up a link on their site now. http://docs.yahoo.com/info/misc/contributors.html Nice to get the recognition.

    5. Re:Commercial addons restricting by King+of+the+World · · Score: 1
      Ah... thanks.

      Could PHPA become part of the base PHP distro? Have such a thing ever been proposed or considered? Why is the sky blue?

      --
      --Giving to trolls for the benefit of us all
  5. Bringing it all together by babbage · · Score: 2

    What a coincidence, I was just looking over this stuff this morning. Does anyone know how close we are to being able to run PHP with Apache2.0, preferably (but not necessarily) on Solaris? Looking over PHP4.2.1 notes this morning, it looked like Apache2 support still wasn't there yet, and some people seemed to be having problems building the language on Solaris. Does PHP4.3.0 address those problems? Should I take "Alpha" to be the warning that it sounds like it is, or would it be safe to try it out now? Would it make more sense to stick with PHP4.3.1 and Apache 1.3.x for now? I'm sure those should build okay....

    --
    DO NOT LEAVE IT IS NOT REAL
    1. Re:Bringing it all together by elemental23 · · Score: 1

      Should I take "Alpha" to be the warning that it sounds like it is, or would it be safe to try it out now?

      To quote from www.php.net:

      This is an alpha version. It should not be used in production or even semi-production web sites.

      I would take their word for it :)

      --
      I like my women like my coffee... pale and bitter.
    2. Re:Bringing it all together by Anonymous Coward · · Score: 0

      PHP 4.2.1 works fine for me with Apache 2.0.36. I've done it on Windows, I've done it on FreeBSD. It's still beta-quality (fine for development, but don't let your daughter date it.) One of PHP 4.3.0's main features will be production quality support for Apache 2. I can't address any of the Solaris issues. This release here is alpha code based on 4.3.0's tree, not 4.3.0 alpha.

      If you need production quality today, they recommend Apache 1.3.24 and PHP 4.2.1. If you just want to play/develop, then you can give Apache 2.0.36 and PHP 4.2.1 a try and it may work. If you want to test out these new features, then you can try out this alpha.

    3. Re:Bringing it all together by g_dancer · · Score: 1

      The Zend Engine 2.0 will not be part of PHP 4.3.0. The mentioned Alpha Release of the Zend Engine 2.0 ships with the current development version of PHP, which is what PHP 4.3.0 will released from.

    4. Re:Bringing it all together by MisterP · · Score: 1

      I compiled Apache 2.0 and then PHP 4.2.1 as a DSO on Solaris 8 (latest patch cluster) without a single issue. It was as simple as ./configure; make; make install. I was expecting big headaches but it went smooth! I haven't tried anything beyond simple web pages, but it seems to work.

  6. Alpha version by Wonko42 · · Score: 3, Informative

    It should have been pointed out in the article that this is an ALPHA version based on the 4.3.0 tree. This is not 4.3.0.

  7. Stupid me by Wonko42 · · Score: 2

    Now that I re-read the title, I see that they mentioned that after all. Ignore me.

  8. PHP Accelerator by Hansele · · Score: 1

    Folks if you want a good, FREE replacement for Zend's Accelerator, go check out PHP-Accelerator

    Nick has written a brilliant piece of work, and its in use on a number of fairly high traffic PHP-enabled sites, including DealHunting.com and GamingForce.com. Anyway check it out.

  9. Nice try but... by Anonymous Coward · · Score: 0

    PHP is by far one of the buggier languages I have used. It's OOP is terrible, granted it was never thought to be one in the beginning and is a constant hack job.

  10. php.net, caches, shady practices, and Re:Commerci by phpa · · Score: 1

    Part of the distro? Probably not. Even if I released the source, I think that what it's rather a sensitive area. (Not hard to imagine why, right?!)

    Even getting a link on the php.net page or in the manual is frankly unlikely. But if enough people pressured them who knows?

    Personally I think that every PHP user should be made aware of PHPA, APC etc., and the user should then be able to decide if any and which of the solutions are for them. I'm convinced that there are many folks who are only aware of the commercial solution, and entirely unaware of any alternatives at all.
    IMHO, php.net are surely doing the PHP community a grave disservice by *not* publicising other solutions that can, after all, make PHP more palatable for some. I firmly believe in an open market where products compete purely on their merits, and not backhanders or the use of veiled threats to win commercial advantage. Of course I'm not suggesting that php.net are tainted by such practices, although if not, adding a link to PHPA, APC etc. shouldn't really be a problem,, should it ;)