Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
PHP Programming

PHP5 Coming Soon 135

Posted by krow from the its-like-hee-haw-with-lazers dept.
Grip3n writes "PHP5 is well under development and a beta is expected out by March 2003 and released summer 2003. One of the more notable improvements which many PHP developers desired is a substantial improvement in PHP's performance. This is due to a new object model PHP5 will be introducing which handles objects by reference rather than by value. Co-creator Zeev Suraski states the new object model is inspired by the book, "Design Patterns"."
This discussion has been archived. No new comments can be posted.

PHP5 Coming Soon More

PHP5 Coming Soon

Comments Filter:
  • Who says Moore's Law is obsolete [slashdot.org]

    • Re:Moore. (Score:3, Informative)

      by Alizarin Erythrosin ( 457981 )
      Moore's Law has NOTHING to do with this. Moore's Law has to deal with the density of transistors on an integrated circuit.

      The observation that the logic density of silicon integrated circuits has closely followed the curve (bits per square inch) = 2^(t - 1962) where t is time in years; that is, the amount of information storable on a given amount of silicon has roughly doubled every year since the technology was invented. This relation, first uttered in 1964 by semiconductor engineer Gordon Moore (who co-founded Intel four years later) held until the late 1970s, at which point the doubling period slowed to 18 months
      • Oh, come on. Moore's "law" has been applied to all sorts of situations, as it's become a part of the general culture, not just geek chic.
  • so, they're planning to release the beta 10 months ago?
  • ...that it'd be hard to "expect" something to be out by March 2002.

  • Good (Score:1)

    by Aztek ( 260107 )
    It needs it. The zend engine needs to be redesigned to include class deconstructors and privite members.

  • Where is it? (Score:2, Insightful)

    by phnx90 ( 208011 )
    How come there is no mention of this on the PHP Website?

  • PHP & XUL (Score:2, Interesting)

    by Mas3 ( 620769 )
    Is there a (larger) web-application which uses XUL generated by php ?
    I Just found small things like single forms.

    Those apps would have the advantage that you can combine a usable & nice looking GUI with a web application (which can be used from everywhere.)
    GUIs designed with HTML are usually quite limited.

    --
    Stefan

    DevCounter [berlios.de] - An open, free & independent developer pool
    created to help developers find other developers, help, testers and new project members.

    • See http://books.mozdev.org/chapters/ch12.html for an introduction to using PHP with XUL.
    • Those apps would have the advantage that you can combine a usable & nice looking GUI with a web application (which can be used from everywhere.) GUIs designed with HTML are usually quite limited.

      You are right. I am tired of trying to force HTML+DOM+JavaScript to *act* like the GUI that the manager/customer has in mind.

      I have been hoping from something like XWT or SCGUI (my pet protocol), but if XUL comes fairly close and catches on, I will be happy (assuming somebody will pay me to do XUL apps).

      Real GUI's again. Feels sooo good, Baby!

  • Porting (Score:4, Interesting)

    by eddy the lip ( 20794 ) on Tuesday December 17, 2002 @06:52PM (#4911779)

    This sounds like a very good thing, and will address many of the things I find cumbersome about the language (namespaces!). But while it sounds full of objecty-goodness, does anyone know how backward compatible this will be with PHP4? It sounds like major changes are in the works, and rewriting my code in six months sounds about as much fun as putting pencils in my eyes.

  • a beta is expected out by March 2002

    maybe I'll ditch ASP for PHP after all.

    • Actually you wi/ould havn/willn-dropped ASP already/soonest, and in fact I right now am holding a copy of your rather excellent review on PHP5-RC3 dated last summer and titled "What you could/id expect from the past/soon PHP5 final release, which will/wasn released yestermorrow."

      That minor eccentric wobble you all just felt in the Earth's axis of rotation is Douglas Adams spinning in his grave. :-)

  • Funny, I didn't see it. :-P

  • *AMP (Score:3, Interesting)

    by Cokelee ( 585232 ) on Tuesday December 17, 2002 @06:59PM (#4911849)
    From the article: PHP runs seamlessly under Windows, as do MySQL and Apache. WAMP anyone?

    IMO this is what makes *AMP. Consistency between platforms. I use Apache, MySQL, and PHP religiously, and no matter what kind of machine I'm running everything on it is seamless.
    I'm not saying this isn't true with other scripting languages, but being able to code on anything with a few tools no matter where I am is EXCEPTIONALLY nice.
    PHP's use on large web application projects has been uncertain. Yahoo [slashdot.org] doesn't feel this way. Neither does Earthlink (WebMail) [earthlink.net]

    But I suppose perception needs to change--you don't have to have a billion dollars [Article, still reading it. . .] [billparish.com] in the bank to make a great web language. (*cough* M$ *cough*) Neither do you need a couple thousand to deploy a website with dynamic content.

    • Re:*AMP (Score:3, Insightful)

      by sporty ( 27564 )
      I just wish that there was a way to compile PHP into some sorta byte code. 'cause then you'd write your Mysql, XML, expat, imagemagik, and other php modules IN php. THEN it'd be truely portable.

      Problem is, if your php module you wish to compile in isn't written for your system, your are screwed. Besides, using your language to develop your language forces the language to be bulletproof after age.

      I've run into some oddities with php when you push its limits.
      • I just wish that there was a way to compile PHP into some sorta byte code. 'cause then you'd write your Mysql, XML, expat, imagemagik, and other php modules IN php. THEN it'd be truely portable.

        What's your logic?

        Having PHP compile to bytecode wouldn't increase the portability of the extension that interface with libraries and apps written in C. If you want an XML parser to work on all platforms you could write it in PHP. A lot of languages that already perform well enough to write libraries in do that rather than doing it in C. Even with PHP compiled to bytecode, it would still have to interface with those C extension dynlib/.so/dll files.

        It might be a bit easier to maintain ports of PHP extensions if PHP had a FFI (foreign function interface) that was workable at runtime rather than requiring a specific C extension to be written for it. Languages with such an FFI (Smalltalk, Lisp and others) often can call into shared libraries on the platform with a lot less trouble and extra code.

        The only real way around this portability problem is to write everything in PHP or a language with similar portability. There's no reason you can't write an XML parser or image manipulator in pure PHP. Bytecode has nothing to do with this though, other than perhaps increasing PHP's speed to something more workable.

        It's easy to push PHP's limits- it was meant to do relatively simple web templating. And sure, it's great at that for some people's use of it.

    • Re:*AMP (Score:1, Funny)

      by Anonymous Coward
      So if swap out IIS for Apache, I'd have a WIMP system :)

      But then if I use Postgres instead of Mysql, I'd have a WIPP system. So is that Pussy WIPP'd or is it that it can WIPP everyone elses ass?
    • Funny thing is from Yahoo's own slides it would have seemed that Perl would have been the best choice (assuming they had equal access to good PHP and Perl coders).

      Referring to:
      http://public.yahoo.com/~radwin/talks/yahoo-p hpcon 2002.htm

      YSP = mod_perl.

      From the slides, YSP beats PHP on performance. Just as manageable (PHP still requires discipline). Lots of existing Perl code doing other stuff. YSP uses more memory - but what's 900MB(YSP) vs 850MB (PHP)at 500 concurrent requests?

      BTW: the page uses javascript where href would do (top 10 web design mistake). Doesn't give me a good impression of cluefulness.

      References:
      http://public.yahoo.com/~radwin/tal ks/yahoo-phpcon 2002_files/slide0041.htm
      http://public.yahoo.com/ ~radwin/talks/yahoo-phpcon 2002_files/slide0002.htm
      http://public.yahoo.com/ ~radwin/talks/yahoo-phpcon 2002_files/slide0003.htm
      http://public.yahoo.com/ ~radwin/talks/yahoo-phpcon 2002_files/slide0004.htm
      http://public.yahoo.com/ ~radwin/talks/yahoo-phpcon 2002_files/slide0005.htm

      So why did they really choose PHP over Perl?
      The given 3 Perl cons, and the "Why PHP slide" are a bit weak IMO.
  • ... because their website just collapsed under the collective weight of /.

  • I blame PHP... (Score:3, Interesting)

    by Dr.Dubious DDQ ( 11968 ) on Tuesday December 17, 2002 @07:26PM (#4912062) Homepage

    I've been blaming PHP for the fact that I haven't gotten around to learning much of Perl or Java - I've been able to do everything I've needed to so far (Nothing TOO complex, obviously) with PHP. I've been "going to start playing with Java to learn it Real Soon Now" for well over a year at this point...

    On the other hand - from the article:
    "PHP5's object model has syntax very similar to the Java programming language, so it will be easy for J2EE programmers to learn it"

    Using PHP as a metaphorical stepping stone to learn Java then?...works for me...

  • Jeez, I just can't wait for March 2002 to come around.

    However, if time isn't circular, then we won't be getting any beta :(
  • Does anyone know if there's a push to port PHP to Windows? ChiliSoft ported ASP to *nix and you can do the mod_perl thang (well, almost) with ActivePerl under IIS, so it must be possible. Eh?
    • Uh, have you looked at the PHP downloads [php.net] website? Listed right under the source code tarballs are Windows binaries in both Zip files and Windows Installer Packages (MSI's) that configure Apache, IIS, and a couple other Windows webservers.

      If you scroll down a bit further, you'll also notice Windows binaries back to 3.0.17

      So, yes. They have ported PHP to Windows.
    • Gimme some of that stuff you've been smoking man. It must be really damn good. PHP has been available for Windows for as long as I've used it...
  • php is the best whether it is version 4 or version 5 ... also taken from here [theopenenterprise.com]
    "PHP is not a blindingly fast language, especially when handling large code bases," notes George Schlossnagle, a PHP performance expert and principal consultant at Omniti, an Internet consulting company. "The lack of built-in script caching and language optimization make its out-of-the-box performance disappointing. Fortunately, when configured and tuned correctly, PHP can provide performance on par with Perl and ASP. "

  • Issues with PHP (Score:3, Insightful)

    by pyman ( 610707 ) on Wednesday December 18, 2002 @02:30AM (#4914196) Homepage
    I have been using PHP for about 4 years, and I quite like the language. I would much rather use PHP than Perl, VBscript or Jscript.

    However there are some things which I think need to be cleaned up.

    The language is a great big mud puddle of libraries and helper functions. It would be nice if libraries could be imported at script run time (They could be sitting in memory waiting to be imported to negate speed issues) instead being available all the time. Ie If you want to use a function you must explicitly import the module containing the function. Why do I need MSSQL, Postges and MySQL connectivity all at the same time?

    And I really hate prefixing all variables with '$'. Maybe they can do something about that...?

    • And I really hate prefixing all variables with '$'. Maybe they can do something about that...?

      And maybe C should get rid of the *'s for pointers, they look ugly.

      Seriously, one of PHP's great strengths is the very nice and simple "do what i mean" syntax, which would be much harder without an easy way to distinguish variables.

      Perl is even more flexible with how you write things, but it has @'s and %'s everywhere. I think PHP has a good compromise.

    • Re:Issues with PHP (Score:3, Informative)

      by ProfKyne ( 149971 )

      Um, if you did that then you wouldn't be able to embed your variables in a string, Perl-style.

      • PHP: "My name is $name\n";
      • Java: "My name is " + name + "\n"

      If you think about it, the PHP way is easier.

      • Um, if you did that then you wouldn't be able to embed your variables in a string, Perl-style.
        • PHP: "My name is $name\n";
        • Java: "My name is " + name + "\n"
        If you think about it, the PHP way is easier.
        Why not this way:
        name = "Lemming";
        ...
        "My name is $name\n";

        Combines variables that are easier to write with embeddable variables. Or is this too inconsistent?

        However, I do see another reason against it. At the moment you can do this:

        $func = "foo";
        $func("bar");
        function foo($arg)
        ...
        With "$func" being written as "func" the parser would no longer be able to recognize func as a variable rather than the name of the function "func()".

        Of course you can always use eval(), but I like the $func() or even $$var [sic] thing very much...

        • That's an interesting alternative (your solution at the top). I hadn't thought of it. Though I suspect that you're right, it's kind of confusing. To be honest, I never found much problem with prepending a $ to variable names, having started programming in PHP and then moving to Perl. In fact when I started to learn Python and later Java, I had a hard time distinguishing the variable names from the operators and method names because I was so used to looking for dollar signs.

          • Well, I learned JavaScript, then Perl, then PHP (and Pascal in between, but that's a different story). I don't really have a problem with the $ as well. There are other characters that I dislike more, mainly because they are just not easy to type on German keyboards (like {}[]\|~@ - you have to use Alt Gr for them).
            The $ makes it more obvious that it is a variable you are dealing with (like you said), and it even makes sense as a sign for "value" (yes, just a thought).
            Really bad is -> for objects. I hate that. I love using object.element instead of object->element and I'm very glad that Perl 6 will do so, too. Though _ is not the best string concatenation character, because, well, it's Shift+- on German keyboards, while . is just .

            If you want to design a language that has as few special characters as possible (like Python), you should have a look at $, too, but since we're talking about PHP here, it does not really make sense. $variable is cool. variable is not.

            Now scan through the text and try to find all variable names :)

            • Yes, dot notation is ten times better than -> for separating instance names and method calls.

              If you want to design a language that has as few special characters as possible (like Python), you should have a look at $, too, but since we're talking about PHP here, it does not really make sense. $variable is cool. variable is not.

              I don't know all of the Perl "special variables", but I'm pretty sure that "$," is one of them. :) If the German keyboard is not conducive to special characters, then you must really hate coding in Perl!

              • I don't know all of the Perl "special variables", but I'm pretty sure that "$," is one of them. :) If the German keyboard is not conducive to special characters, then you must really hate coding in Perl!

                The most bad characters, [], {}, \ are very often used in other languages, too. Array indices, block delimiters, escape sequences, you have that in PHP as often as in Perl. $ is Shift+4, that's okay. It's not like I use the special variables in Perl more often than those characters, far from it. And most of them are even okay (especially "$,", since I do not even need shift for the ,). Okay, the @ for arrays is not that good, but what really sucks are constructs like @{$var} - in these areas Perl is especially uncomfortable.
                Perhaps I'll find a nice way to use the American layout for coding and the German layout for the rest of my tasks... though this is not ideal, too, since the printed characters on the keyboard are German layout forever.
                • i've seen these things in Fry's (large US computer parts and every-damned-thing else chain, imagine a store larger than a Wal-Mart packed to the rafters with geek stuff) that are USB-attached programmable keypads (most of them have had something like a 5x5 or 6x6 array of keys, with some relabeling mechanism so you can label each key with what you programmed onto it). Maybe you could grab something like that and program it to generate all the troublesome characters? (googling for a minute lead me to P.I. Engineering [ymouse.com], makers of a device that might suit your needs (albeit at ~100 USD))
                  • I don't really think that these things would help me. You know, I *am* able to type those characters, it's just not very convenient. I guess having to use a different device is even worse. It definitely has it's uses, but not as a keyboard extension for typing.

                    I will probably play around with XP's keyboard layout switcher. You can assign hotkeys to switch between layouts. It is even enabled by default AFAIK, but sometimes the layout is switched though you did not intend to do so... I'm not sure why, I just disabled the feature. I'll see...
              • To get a better idea of the German keyboard layout, here are some pictures in normal [denniskehrig.de], shift [denniskehrig.de] and in alt gr [denniskehrig.de] mode.

                • It must be more convenient for typing in German.

                  • > It must be more convenient for typing in German.
                    I'm sorry - what do you want to say with that?

                    • [The German keyboard layout] must be more convenient for typing in German [otherwise I would think it easier to simply use a US keyboard layout].

                    • Thank you :)
                      I did not do a strict comparison of both, but the main reasons for using the German layout are, of course, german characters: äöüÄÖÜß. The only difference regarding normal characters are z and y being switched (QWERTZ instead of QWERTY), which makes sense, because z is used more often than y in German. But I bet that the layout is still far from optimized...
                      The numpad has , instead of ., which is normally good, but sucks for entering IP addresses... I should really try the keyboard layout switcher. And once I'm grown up, I will build better keyboards :)

                    • But I bet that the layout is still far from optimized...

                      I think this is true wherever non-Dvorak keyboard layouts are being used, isn't it? I told myself that at some point I'd have to learn the Dvorak keyboard too, but ... well I type pretty fast already, and I don't know if Dvorak is optimized for coding.

                    • AFAIK Dvorak ist optimized for the english language. I also wanted to learn Dvorak, but it's kind of useless for me without the german special characters. German is still my "main" language. :)

                    • Possibly there is a Dvorak-style keyboard layout for German? (With the most frequently-used letters in German in all the right places.)

      • There's alwqys the Ruby Way.

        "My name is #{name}\n"

        where 'name' can be any expression, not just a variable name.

        • I haven't learned Ruby. I wonder what other features it has that distinguishes it from Python or Perl.

          • Many. Read the book [rubycentral.com].
          • That's not really a feature that distinguishes Ruby from Perl.

            With Perl you can do something similar:
            print "Result is: ${\( myfunc($somevar)*2 ) } bars";

            It's a tad uglier, but still practical. That's perl for you ;).

            It also works with the <<"HERE"; stuff.

            Stupid that selecting "plain old text" in slash still requires me to use &lt; to represent '<'s

            • You make a reference to a value and then dereference it. Neat, I didn't think of that. But not something I'd ever use in a release script (too ugly!) ;). Thanks for sharing.

              • You're welcome - I copied the idea from some site when I was learning Perl + DBI + CGI. Can't find the source at the moment.

                I've actually used it in production stuff.

                Though it is indeed ugly, it's convenient enough when you want to use the output of a few functions right in a multiline string. And you don't feel like creating a few throwaway variables a few lines up, just to stick them in the string.

                Explaining it to some people is a bit less convenient ;). So I'll be happy to learn of other alternatives.

                TMTOWTDI :).
    • agree... I would love to have time to migrate all my asp stuff over. asp2php is mabye an option.. but that could turn into a pain in the tail

  • Using design patterns (Score:4, Interesting)

    by Wizard of OS ( 111213 ) on Wednesday December 18, 2002 @03:20AM (#4914314)
    The quote above states:

    Co-creator Zeev Suraski states the new object model is inspired by the book, "Design Patterns".


    While this isn't false, it did get me on the wrong foot. It appeared to me as if the PHP developers were just realizing that stuff like design patterns exist, and started writing their code accordingly. THe article however states:


    "The way PHP4 was built -- it was not easy to implement design patterns," says Suraski. "PHP5 is much more suitable, so you will be able to take that book and implement the design patterns in your code."


    It would've been helpful if that quote had been in the post, but it makes clear that PHP5 will have much better OO features than PHP4 currently has.

  • One person's experience with PHP ... (Score:4, Interesting)

    by tdelaney ( 458893 ) on Wednesday December 18, 2002 @05:43AM (#4914606)
    ... and why I won't go back.

    PHP 4.2.3. Windows 2000.

    90% of the way into a decent-sized project, I started experiencing somewhat random crashes. Somewhat random in that there seemed to be no consistent way to provoke them, but once they started happening they happened in precisely the same way, consistently.

    Simple changes, such as adding a single character to a script, would "fix" it on a particular machine ... and sometimes expose it on another machine. I'm talking about adding a blank line to a script. It seemed likely that there was a memory error of some kind in PHP.

    Downgrading to earlier versions of PHP 4.x didn't fix the problem. Downgrading to 3.x was not feasible ... transferring to a 3rd-party session system that was incompatible with the 4.x sessions and completely untested by us was not possible by that time.

    Of course, I attempted getting the source code and finding the problem myself. Unfortunately, none of the 4.x versions would compile. The 3.x versions would - but 4.x wouldn't. Obviously, some black magic was required. Sacrifices failed.

    Time was running short. Faced with a very short deadline, I made the only decision I could ... I dumped PHP. I was in a situation where I could not trust the underlying technology.

    As an indication of what dire straits I was in, the technology I eventually recommended to replace PHP and Apache was ... IIS 5.0 and Active Server Pages. Believe me ... if there had been any other viable option, I would have taken it. mod_python looked viable at first, but I didn't have time to go through the cycle of building a single-threaded python, and verifying the underlying technology. With ASP there was a fairly direct translation from PHP.

    I hate that this application has been written in VBScript. The shenanigans I had to go through to get a particular COM control to load and be controlled by IIS - it's system of impersonation doesn't work very well if the COM object isn't specifically designed to be used with it. Under Apache it was able to run as LocalSystem ... which was acceptable since the users are trusted. Under IIS I eventually needed to create an administrator user which a single page uses - all other pages use a Guest user.

    Obviously I was doing something outside the norm, since there are thousands of web sites which use PHP as the underlying technology. I suspect most of them are running 3.x. But the sheer number of issues that I found with PHP during the relatively short development cycle convinced me that it was in no way mature enough for us to trust our work to it.
    • You were probably running it as an ISAPI module instead of in CGI mode. I've had problems on Windows boxes running it as an ISAPI module, it even says the ISAPI version isn't stable in the read me, but I haven't had any problems running it as a CGI.

      Your ASP/COM problems sound weird to me. if you haven't already, look into using MTS/COM+ with that object.
    • Just as an FYI from somebody who has written a lot of code for oil companies (read: welcome to NT-land, hope you enjoy IIS!), you can use much nicer languages than VBScript as your ASP language. JScript is much less of a syntactic jump than vb from php, and if you can get approval to install ActiveState's perl, you can use PerlScript seemlessly (and perl for the simple uses you'd have in a webapp would take any decent php coder less than a week to pick up fluently). So you gain the "home-field" advantage of IIS/ASP/COM, with a decent language to code in...
      • Whilst you *can* use JScript, it really isn't as well supported as VBScript. VBScript is the "native" ASP language, and everything else is a second-class citizen.

        One of the reasons for moving to ASP/VBScript was familiarity - much to my dismay, I have written extensive amounts of it :(

        I've also used PerlScript before ... for a single project. I gave up on Perl once I started looking at the so-called "object-oriented" aspects. Python is so much nicer.
    • Sorry, but that's not fair. For some reason, it's as if they completely and totally forgot to do regression testing w/ the goddamned release.

      utime doesn't work. That means
      touch doesn't work.
      gzip doesn't work.
      error messages don't get reported.

      I begged my boss to roll php 4.2.3 off the servers and he did as soon as he saw what I was talking about...

      Other versions of php are just fine, check 'em out!
    • Next time try looking into Zope [zope.org]. It's an outstanding platform for web-applications and dynamic web content.

      It sucks for static through-put of files, however, so if you plan to serve large files stick with Apache. But if you want dynamic content -- go Zope.
      • The site was originally specced to use Zope (which I would have been very happy to use ... been wanting to have a look at the ZPT for some time).

        However, the decision was made by someone (I'm not sure who - it was before I came onto the project) that Zope was too heavy-weight for what we wanted.

        By the time PHP failed, it was too late to go to Zope ... the approaches to web development are just so different between the technologies.

        Basically, ASP was the one technology where I could (almost) guarantee having the site in an equivalent state to the PHP version in the time frame. A purely risk-management decision (including the risk of bugs in IIS, etc).
    • Don't tell me it never occured to you that those random crashes could be due to the fact that you were running it on Windows! I'm not saying that they were, but it doesn't sound unreasonable to me. AFAIK, random crashes are Windows's trademark...
      • Actually, it was the very first thing that occurred to me. I spent a lot of time investigating the possibility.

        The point is though, that *random* crashes are a Windows trademark - not crashes which appear to be random in how you provoke them, but consistent once they start happening.
    • I'm not buying it...well, I was until the IIS & ASP promo came along.

      t'iz a poor man that blames his tools...
      • I hate IIS and ASP. It sucks. I avoided recommending it for as long as I could as I evaluated other alternatives. The fact that I was willing to recommend it told everyone exactly what a shitty situation we were in, as they knew I would only do such a thing if it were the only viable alternative given the time frame and available skillset.

        Does that sound like a promo to you?

        I've posted a lot on this topic - more than I've ever posted on a topic before. Why? Two reasons.

        1. To clarify some misunderstandings about the situation (what technology was used, and when).

        2. Many people seem unwilling to accept that *sometimes* an open-source tool is less suitable for a particular purpose than a proprietory tool.

        I'm not saying that IIS and ASP were *good* tools. But they were more usable for our needs.

        If it had not been for that one single showstopping bug the web site would be using PHP right now, despite the other flaws we found.
  • ...just stick with Zope.

    It's by far the best dynamic content management system out there. And the underlying language, Python, is easily the best too.
    • ...or why python is better on the backend and the front-end.

      Take namespaces for special-purpose library stuff. Or inline eval (include) of logic code (bad, bad, bad). Good analysis (mine) here, including comparitive code to demonstrate my point. [zope.org]

      Like Java, Python already does assignment by reference, copy is optional. PHP is just figuring this out. PHP's language leaves much to be desired in team programming and code readability. Using 'Design Patterns' is only half the equation. You can do component oriented programming, but some languages are going to be better than others at facilitaing it in a manner that works in reality. PHP5, unfortunately, won't hold a candle to Zope 3 [zope.org], which is really going to compete at the level of J2EE and .NET as well-thought-out enterprise component frameworks.

      PHP lacks object persistence, multiple inheritance, full-featured transaction machinery, a built-in security model, an interactive command-line interpreter, and it is too tied to web-scripting only. And becuase it doesn't have a security model that binds operations to roles/permissions, it can't easily put gateway methods with bound roles (like Zope's proxy roles) between web code and SQL code, leading to increased chance of SQL injection vulnerabilities.

      On the other hand, Zope has object perisistence, transactional RDBMS integration and connection abstraction, templated, componentized SQL methods, a security framework, and Python, which is a much better language (explicit is better than implicit). And if you need to do any sort of content-management, Zope has a mature component-oriented framwork in the CMF [zope.org], with a killer-app implementation in Plone [plone.org]. It also has XML-RPC, WebDAV, Caching managers, and all sorts of other goodies you won't find out of the box in PHP.

      PHP is fast, and it is easy, but it is by no means scalable. PHP offers a gentle slope learning-curve, and quick easy hacks, but is somewhat like a crack addiction. What PHP as a framework needs to do is not reinvent the wheel in the language department, and use a pre-existing, scalable, enterprise-class OO scripting language, and utilize a templating technology that doesn't promote mixing logic and presentation - but what's the point, since it would look remarkably like Zope?
      • Heh... I was gonna write something similar to that, but ended up with my quick-and-dirty few sentences. Color me lazy. Oh, and BTW... mod parent informative, please!
      • And for your next trick, you'll compare a language to yet another framework, right? Hrmmm... .NET server has 14,000 class libraries, but PHP doesn't have those. Websphere offers (foo) but PHP doesn't. PHP must suck.

        Pretty much all of what you offered there is available in free or commercial frameworks, and the rest is opinion, not fact (python is 'better' - good argument).
  • Does anyone know how much rewriting there will have to be to migrate to PHP5? We're using OO in some applications now. Will the way we instantiate objects and reference properties remain the same?
  • I guess there isn't always a good way to maintain backwards compatability, but it does stink to go back thru large chuncks of code fixing stuff :)

Slashdot Top Deals

Don't get suckered in by the comments -- they can be terribly misleading. Debug only code. -- Dave Storer

Close