Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
PHP Programming

PHP 5.1.0 Released 275

Posted by Zonk from the hello-darkness-my-old-friend dept.
kv9 writes "A new release of PHP5 is available. This version includes over 400 bugfixes, performance improvements over the 5.0.x branch, new date handling code, new versions of PCRE/SQLite/PEAR and over 30 new core/extension functions. A number of security fixes are also present and users are recommended to upgrade."
This discussion has been archived. No new comments can be posted.

PHP 5.1.0 Released More

PHP 5.1.0 Released

Comments Filter:

  • mySQL support (Score:5, Funny)

    by Anonymous Coward on Friday November 25, 2005 @10:50AM (#14112916)
    MySQL support has been droped in favor of using simple flat text files. The performance increase from this has been HUGE and the feature set is the same.

    • Re:mySQL support (Score:2, Informative)

      by ajs318 ( 655362 )
      What is it with the MySQL bashers around here? Have you actually used it or are you just content to parrot what you have heard elsewhere?

      For read-only, or even read-mostly, MySQL is blisteringly fast. It slows down when doing many INSERT or UPDATE queries on large tables because the whole table is held in one file, which has to be locked during a write and so slows things down.

      On Linux, with a disk caching policy of "Never, ever commit anything unless you have to swap something from RAM, or are about

      • Re:mySQL support (Score:5, Insightful)

        by CyricZ ( 887944 ) on Friday November 25, 2005 @11:31AM (#14113147)
        A lot of people who criticize MySQL have directly used MySQL. What we've found is that for lighter tasks (such as many webpages), SQLite often works quite well. And once/if you need a database system that's more capable, it's best just to move to PostgreSQL.

        The recent Oracle/InnoDB and MySQL AB/SCO debacles have also made many potential MySQL users weary. There are many users who are now questioning how viable MySQL will be in the near future, both from a technical standpoint with regards to the InnoDB purchase by Oracle, and from a legal standpoint concerning their dealings with SCO. SQLite and PostgreSQL do not suffer from such unknowns.

        • Some more alternatives to MySQL (Score:5, Interesting)

          by Elrac ( 314784 ) <carl AT smotricz DOT com> on Friday November 25, 2005 @12:11PM (#14113341) Homepage Journal
          I apologize for being a bit off topic, but I'd like to throw in a couple of cents' worth on newly emerged alternatives in the "free DB" arena. Hopefully PHP support for these will be forthcoming forthwith:
          • IBM has spiffed up Cloudscape to be somewhat compatible to DB2, renamed it to Derby and is giving it away
          • Oracle is giving away a mildly crippled version of its DB, I don't remember the exact circumstances
          • ADABAS, also known as SAP DB, is now also FOSS
          • Firebird, née Interbase, was freed years ago and is said to be working well and under active development. I don't know why so few people seem to like it.
          • I believe I heard about SQL Server being "free" under some circumstances too, but I'm not sure.
          So... many thanks to MySQL for being a forerunner in the "free DB" department, and more thanks to other, formerly proprietary-only vendors for making their products a little more accessible to the common man!
          • PDO [php.net] is a free solution to most of these. It's slated to go stable this weekend.

            IBM has spiffed up Cloudscape to be somewhat compatible to DB2, renamed it to Derby and is giving it away
            PDO_ODBC [php.net], Zend Core for IBM [zend.com]

            Oracle is giving away a mildly crippled version of its DB, I don't remember the exact circumstances
            PDO_OCI [php.net], Zend Core for Oracle [zend.com]

            ADABAS, also known as SAP DB, is now also FOSS
            This one, I know very little about..

            Firebird, née Interbase, was freed years ago and is said to be working well and under
        • WHo cares? PHP-5.1 introduces PDO from pecl into the mainstream distro. The idea of course being that it doesn't matter what is behind your scripts as long as PDO is used. Consider it DBI essentially. So your app can work with sqlite, mysql (transactions or not), postgresql, etc. in a much more consistent manner.. Sure there may be slight variations, but stick to the SQL spec and you should be okay.

          -M
          • I do recall that someone [nyud.net] didn't want PDO to be built into PHP. I personally use ADOdb Lite [sf.net], the much faster version of ADOdb [sf.net]. Now if it weren't such a bitch to port code between different APIs, I'd gladly try out every API under the sun, but for now, ADOdb is fine. Now if only there was a Perl DBI module for PHP and we'd be set. PHP needs more of that.
            • You'll also note that "I'm working on an alternative at present." is at the top of that article. So note the bias. Of course not everyone will like every extension, addition, or modification in many languages- you get used to a certain style and way.

              He is bashing the specific implementation, but the concept is the same. PDO is _A_ solution. It's a good solution. It is technically very stable. It working out of PECL (and just a base is distributed with PHP-5.1) means for easy updates if compiled with s

      • Re:mySQL support (Score:3, Interesting)

        by kpharmer ( 452893 )
        > For read-only, or even read-mostly, MySQL is blisteringly fast.

        I think you mean that when doing lookups of a very small (less than 1%) set of data from a single table with simple queries that mysql understands the b-tree index in myisam or oracle's innodb is as fast as any other database. In the case of myisam maybe a little more, in the case of innodb maybe a little less.

        I'm sure you don't mean that when selecting 10% of the data of a single table of the database (thereby unable to do b-tree lookups)
        • Mysql's "amazing speed" is only for weak benchmarks of a single user running queries in serial. Once you start having many users running many different queries at the same time, its performance falls apart. This is where the mysql speed myth comes from, people comparing 100,000 simple select statements in serial for mysql and postgresql, and mysql being faster at it.

          • Re:You forgot one. (Score:3, Interesting)

            by jZnat ( 793348 )
            Oh boy, I can account for this claim completely. I used to co-program with another person on a large website that used MySQL from the start. Him and myself would constantly look for ways of increasing performance and minimising lag, but we never tried using a different database. With a site that massive at the time, we should've been using PostgreSQL at least, or even Oracle or DB2 or similar if we could get the money to buy it. I even went as far as rewriting the entire system with the most optimised P
      • "It slows down when doing many INSERT or UPDATE queries on large tables because the whole table is held in one file, which has to be locked during a write and so slows things down."

        Jesus , didn't realise mySQL was *that* primative. If anyone had
        suggested using that form of implementation for a DBMS 20 years ago
        they'd probably have been laughed out of the room , never mind in 2005!
        You'd be lucky to get away with that even in a college DB project!

  • Sendmail (Score:3, Funny)

    by jrockway ( 229604 ) * <jon-nospam@jrock.us> on Friday November 25, 2005 @10:56AM (#14112948) Homepage Journal
    > A number of security fixes are also present

    I think we've finally found a replacement for the security disaster known as sendmail -- PHP.
    • You know PGP stands for 'Pretty Good Privacy'?

      I think I've worked out what PHP stands for -- "Pretty Hopeless Privacy"
      • So, how long until GCC includes a PHP compiler that's supposed to address all the issues that PHP allows programmers to get away with? :P

        Besides, most of the bad programming practices that PHP allows are due to it being written in C, so your crappy C coding practices will also work in PHP.

  • Many improvement... (Score:4, Funny)

    by masklinn ( 823351 ) <.slashdot.org. .at. .masklinn.net.> on Friday November 25, 2005 @11:00AM (#14112960)

    ...and still no damn fucking namespaces.

    Go PHP, ride on to the 20th century!

    • Re:Many improvement... (Score:3, Informative)

      by Anonymous Coward
      They are considering namespaces for PHP 6 - Read the meeting notes here:

      http://www.php.net/~derick/meeting-notes.html [php.net]

      http://www.corephp.co.uk/archives/19-Prepare-for-P HP-6.html [corephp.co.uk]
    • Hmm, one big reason why Perl is better for large applications.

      • Well put.

        I find it ironic that PHP came out many years ago as a cheap and easy way to make more dynamic web pages with a simpler structure than perl. It was also a greatly reduced structure from perl.

        Then someone added a bunch of MySQL to it, hyped it up as LAMP and now everyone's on that bandwagon. And those that weren't were bitching about how if you want to do a real web application you would be better off using Perl and PostgreSQL.

        And now here we are years alter and from the threads I've seen herei


      • And another big reason is that the perl libraries (ala CPAN) do not require a recompile of perl itself. I cannot count the number of times I go to do something in PHP only to discover that PHP has to be recompiled with the switch to include such-and-such library. Need to work against an Oracle database in PHP? Bring down the production web servers to install a new PHP with OCI support enabled. Need to work against Oracle in Perl? Just install the appropriate perl module, no need to do anything drastic.
        • I find that somewhat humorous as well, since the Windows port of PHP allows for exactly what you describe.

          You drop the appropriate DLL's into the system %Path% (which should include the PHP directory) or, if you're using Apache 2, the PHP INI Directory specified in your httpd.conf. Alternatively, you can add them to your php.ini's extension_dir, whatever you set that to be. Then you edit the PHP.INI file and uncomment or add the modules you want to use. Then restart Apache and pray. I say "pray" because Apa
    • Couldn't one abuse classes as namespaces?

      The only thing missing is the ability to alter the class def a la adding "friend"s

      • Yes, one can kid-of-emulate namespaces using classes (AFAIK people have done it in fucking Javascript for years !).

        But

        • It's impractical, having to jump through hoops to get a module sanely stored in it's own namespace is stupid, annoying and time consuming
        • It has many shortcomings and limitations
        • And last, but not the least, it doesn't clean the global namespace from all the fucking crap that's landed in it since the birth of PHP

        To sum it up, yes you can use the oh so shiny new PHP classes to create nam

    • Namespaces? Like Perl Modules have namespaces starting the main::?

  • Beware of PHP 5.1 (Score:5, Informative)

    by Anonymous Coward on Friday November 25, 2005 @11:02AM (#14112976)
    You don't have any classes named Date, do you? It's an extremely uncommon name. Good thing we have namespaces.

    http://news.php.net/php.internals/20352 [php.net]

    • Re:Beware of PHP 5.1 (Score:4, Funny)

      by Tim Browse ( 9263 ) on Friday November 25, 2005 @01:45PM (#14113867)

      I've only messed around with PHP for my personal website and a small catalogue style website for my parents' business, but I noticed there were no namespaces, so I simulated them by prefixing class/function names with short prefixes, e.g. twbb_GetForumThread() etc.

      I don't envisage having any problems with the new PHP core functions colliding with my names. But then maybe that's because I've worked with other languages that don't have namespaces (e.g. C, which I believe had some brief border-line success/popularity at one point, despite being crippled by lack of namespaces), and also I have a fucking clue what I'm doing. Idiots, on the other hand, will always run into problems.

      That's not to say I wouldn't like to see namespaces in PHP :-)

  • Bug fixes should go into 5.0.x (Score:5, Insightful)

    by halfnerd ( 553515 ) on Friday November 25, 2005 @11:09AM (#14113023) Homepage
    I was under the impression that when using a x.y.z -versioning scheme, bug fixes should be released with increments of z, new features with increments of y, unless they break compatibility, when x should be increased. But when has even PHP done some something in a standard way.

  • Adding even more functions? (Score:5, Insightful)

    by A beautiful mind ( 821714 ) on Friday November 25, 2005 @11:13AM (#14113043)
    "(...)and over 30 new core/extension functions."

    Ugh. Adding still to the inconsistent, namespace mess, PHP functions have? Worst. Decision. Ever.
    • What are the backgrounds of the main PHP developers? Do any of them have any serious credentials, or even background in language design at a graduate level, for instance?

      One thing I find about PHP is that, rightly or wrongly, we always hear about how it's quite lacking as a language. Could that be because it is designed by people who have very little experience designing modern programming languages?

      • PHP wasn't always a "language" (I personally think it still isn't), but as a bunch of Perl CGI scripts, maybe thats why. It wasn't designed to be a language.
      • Since when is language design a grad. discipline? The Zend guys happen to be damn good programmers - have a look at the code of the interpreter.

        • Re:Backgrounds of the PHP developers. (Score:5, Insightful)

          by Elrac ( 314784 ) <carl AT smotricz DOT com> on Friday November 25, 2005 @12:22PM (#14113404) Homepage Journal
          The Zend guys happen to be damn good programmers - have a look at the code of the interpreter
          That sentence illustrates the problem and your lack of understanding of it.

          Design and programming are two distinct disciplines. Some brilliant developers are good at both, but many people, myself included, get too much satisfaction from diving into coding to thoroughly think about what they are embarking on. The result is a program/system/language/whatever that starts with a clean small core but grows ever bigger and uglier as changes are bolted on. I tried PHP a couple years back and was disgusted by it. There's a reason why computer language design is a discipline of an academic subject, Computer Science: A wealth of knowledge has accumulated on how to do this kind of thing "right," and applying that knowledge will usually lead to a better end result.

          Specifically, my beef with PHP summarizes down to: It makes simple things simple in a way that encourages sloppy coding. PHP is to the current would-be Web geek generation what BASIC was to teenage would-be hotshot coders in the late '80s: A way to achieve "gee whiz!" effects easily and cheaply. It's possible to write large, elegant programs in PHP, but that's not what usually happens.
          • But on the plus side of PHP it's a nice convenient stepping stone between plain HTML and the godawful mess of punctuation that is Perl.

            I code in PHP because I can quickly roll out powerful scripts, but the namespaces really need an overhaul.
            • I dunno - when I write Perl, it looks exactly like block structured C and people have no problems reading my Perl code. I suppose it is possible to create a mess in any language, if you try hard enough.
              • You can write perl like that --I do-- but that's really against the Perl culture. Like assuming $_ for many operations. Sure you can state it explicitly but the custom and culture is to assume it. Perl is meant to be written in a 'clever' manner. When I have to write Perl I write it similarily to the way I write my Java code, but that's not really kosher. I once saw code written in Java but in the style of LISP and it was painful. So in summary: writing neat readable Perl code is possible but it is not usi
          • I disagree. Plenty of software in general, and some languages in particular suffer from the "too much design" disease. On the other hand, software which is being written well (for some definition of "well"), tends to outgrow the flaws in its initial versions even if at the end one can hardly recognize that this is the same software.

            The classical example of an "overdesigned" language is Java (I am lousy at separating the language from its APIs). What you get is some more "reuse" at the price of unnecessari

          • Re:Backgrounds of the PHP developers. (Score:4, Informative)

            by dragonman97 ( 185927 ) on Friday November 25, 2005 @03:10PM (#14114245)
            Unlike some of the other replies, I agree wholeheartedly. I am a Perl programmer, who actually has a clue about programming. (And I write legible Perl, thank you very much. [most of the time ;)])

            I've just 'inherited' a PHP project, and I want to scream. I've finally had to 'learn my enemy.' So, wanting to know what the heck I was getting into, I bought a ton of O'Reilly books, and I read through a bunch of "Programming PHP" before beginning, so I wouldn't make the mistake of just slapping together whatever worked. Getting right into it, I was appalled at how poor the 'design' of the language is. It's a poor ripoff of many decent languages, slapped together in whatever Q&D way would 'make it work.' Why are phonetic string comparison functions part of the core language?! Those should be in a library! Why, oh why, was the scoping done so utterly backwards?! I was cleaning up some code, moving it into a function, and suddenly it stopped working. I had realized the answer the first time I tweaked it, but summarily forgot the second time around. What was it? Why, naturally, I had forgotten to do 'global $foo' inside my function - how stupid could I be to think code inside a function wouldn't pick up the contents of the variable as declared outside it?

            *sigh* I've gotten a project with 15,600 lines of 'code,' and already gotten rid of 1200 lines of repetitive junk by applying some common sense to it. I have another 120 lines lined up to be shot today. (A diff -uw of 2 files turned up exactly 5 differences.)

            PHP makes it way to easy for people without a clue to 'write code' that 'works.' Thank you all the same, but I prefer to keep my brain engaged in 'drive,' rather than 'park.'

            • Re:Backgrounds of the PHP developers. (Score:4, Insightful)

              by killjoe ( 766577 ) on Friday November 25, 2005 @06:04PM (#14115106)
              Personally I think the use of the "global" keyword is something PHP got right and every other language (except ruby) got wrong. When you are reading a function it's good to know where all the variables are coming from. In ruby they use a sigil, in PHP they use a keyword, in every other language you have to search through the function to see where and if the variable was declared and deduce that it was either a global variable or a typo.

              To recap. PHP got it right, perl got it wrong. You are annoyed because it's not the way you are used to working but that has nothing to do with the merits of the scoping rules.
          • It makes simple things simple in a way that encourages sloppy coding.
            Frankly, sloppy coding is 99% the fault of the programmer. You sound like a carpenter who's angry at the hammer because he hit his thumb with it.
  • It's widely known that PHP is used by a lot of "developers" without much background in writing secure software. As such, the coding techniques used are often less than ideal, and have lead to numerous security problems in the past.

    Are the PHP developers actively doing anything to help prevent those without much experience from writing code that can lead to a server being compromised? Not that they should restrict those few developers who do know what they're doing, but they should perhaps be taking a look a
    • The main reason for PHP being insecure is the huge amount of functions for "securing" form data before using it in an SQL query. It's just comical that both mysql_escape_string() [php.net] and mysql_real_escape_string() [php.net] exist. PHP should be purged from all of the unused and misused functions soon, or it will never be safe.
    • It is also widely known that many server administrators are known to install many applications as root. PHP and apache, among many others.

      Who should be held responsible for THAT? (Set an X)
      [ ] The Apache developers?
      [ ] The Linux developers?
      [ ] The server "administrator"?

    • Re:Is any work being done to improve security? (Score:2, Informative)

      by Anonymous Coward
      "Are the PHP developers actively doing anything to help prevent those without much experience from writing code that can lead to a server being compromised?"
      They are doing quite a bit actually. PHP6 will see a full input_filter mechanism added, safe_mode (misleading name) removed, and other substantial changes that will deeply improve security for programmers.

      In addition, there is discussion of adding namespaces in php6, a feature that would easily improve security in virtually every app by preventing unint

    • PHP Security (Score:4, Interesting)

      by shiflett ( 151538 ) on Friday November 25, 2005 @11:47AM (#14113231) Homepage

      Some of us are trying to help the situation by educating PHP developers. For my part, I try to write articles [shiflett.org] (and make them available for free), give talks [brainbulb.com] at conferences and user groups, and answer questions on mailing lists and forums.

      There's also the PHP Security Consortium [phpsec.org], the Zend Framework (which will hopefully include most things on my wishlist [shiflett.org] as well as solve other problems [shiflett.org]), and a new input filter extension [derickrethans.nl].

      As BP says, it's a start.

    • Short of removing all input/output functionality, people will always manage to write insecure PHP scripts. I've seen things you people wouldn't believe - SQL injection attacks on fire off the blah, blah blah...

      *Ahem!*

      But anyway. I'm not aware of any built-in security problems - most of what your average Slashdotters regard as 'OH THAT'S SO INSECURE WHY CAN'T THEY FIX IT????' seems to be down to shitty programming by end-users rather than PHP limitations. Idiotic PHP features like magic-quoting of input stri
      • Idiotic PHP features like magic-quoting of input strings seem to be those added in an attempt to improve security, and have ended up acting as a crutch for poor programmers when the 'correct', unchanged behaviour might have broken things more regularly and actually taught a bit of good programming practice.

        Indeed! Microsoft is often criticised for trying to do things for the user, instead of showing the user how to do them. The same criticisms apply to PHP here.

        PHP is renouned for having good documentation;
        • "would it not hurt to have Remember to use addslashes() on any query before running it! in big and bold on any sql-query-sending page?"

          Yes it would hurt. addslashes is actually the _wrong_ way to do things. It is bad design. But it is shameful that even up till now in PHP it's not clear what to use instead. pear db or pdo?

          Whatever it is, you should use a database specific quoting method.

          In perl if you have a db object $dbh you'd call it like this:
          $quoted_stuff=$dbh->quote($stufftoquote);

          However, you shou
        • would it not hurt to have Remember to use addslashes() on any query before running it! in big and bold on any sql-query-sending page?

          Yes, that would hurt because you're supposed to use the dbtype_real_escape_string() function instead. addslashes() practially adds random slashes to hope that it won't fuck anything up.

  • Advances/Alternative to the server (Score:5, Interesting)

    by Kunta Kinte ( 323399 ) on Friday November 25, 2005 @11:18AM (#14113079) Journal
    PHP's big problem is not language features anymore. It's the lack of innovation in the PHP server program.

    Zend refuses to add basic features such as a basic accelerator ( PHP scripts get recompiled on every request ). In fact, there was a rumor that Zend bought and killed http://sourceforge.net/projects/turck-mmcache/ [sourceforge.net], the best accelerator out there because it competed with their commercial product.

    I understand that money has to be made for development to continue, but that's no way to compete.

    PHP server needs true session and application scope variables. File-based session variables it has right now means that any variable that's not serializable ( eg. file descriptor ) can not be saved in the session scope. This is a huge problem. It results in developers making countless round trips to their database to serialize data, and hence making PHP scripts more dependant on close/performant database in general. There was an mmap based solution being worked on, but haven't heard much about it lately.

    Other web environments have had these features for years.

    I'm guessing that that sought of restriction on the PHP server will continue until an alternative server is developed and begins to gain popularity.

    • Do you mean that you can't store objects as session or application variables? I work with ASP, so I just assumed that PHP has had this ability for well... years.
    • PHP scripts can't share file handles like every other program written in i.e. C. I don't see a problem with this. If you need data every time and need it fast you can use shared-memory. There's a nice extension that even works on Windows. If you need to share data between servers you have bigger problems than the time opening a file takes.

      b4n
    • Persistent objects are super, but think of this from a systems perspective. I'd imagine you're thinking of Java, having a nice super-server running and then a small component in Apache sending the actual requests to the Java environment. Now take PHP:
      - each apache process takes some requests. Opening a file-descriptor or database connection in one doesn't mean it'll be available to another process. So the file needs to be opened, database connected to, etc.
      - persistent connections (datab

  • OO (Score:4, Informative)

    by smallguy78 ( 775828 ) on Friday November 25, 2005 @11:21AM (#14113092) Homepage
    I use to use PHP a lot day to day for several years (lamp), and found it kicked the ass of ASP for doing really fast web apps. Bigger web applications however, is where its mechanics started to erode - specically includes and the old module level variables issue.

    PHP 5 brought more OO features but it's still loosely typed and not compiled, meaning its OO features pale in comparison to JSP and ASP.NET. Until these two features are added by default (yes I know there are compilers), I can't really see how people will want to make use of its OO features in a business scenario. It handles strings (atleast in 4) about 50x slower than .net and seems to be stuck between a scripting language and a fully fledged OO language.

    • Re:OO (Score:4, Insightful)

      by moro_666 ( 414422 ) <kulminaator@gmai ... Nom minus author> on Friday November 25, 2005 @12:45PM (#14113529) Homepage
      you forgot to add that real programming languages are pretty much backward compatible, whereas php's backward compatibility doesn't just suck, it's nearly non-existant. references, oop parent class calls, global variables etc. this language gets ever more messed up with every new version and with zillion little configuration flags that affect the very basic functions and breaks down even the most patient code.

      php has it's good sides but it the long run it's definitely the loser platform from my point of view. even perl is more stable and readable after 3 years of support on the same code (on php you either do very expensive upgrades to the software every time there are some major changes or you do cheap fixes and the code turns into a mess).

      have you ever tried to read a well organized OOP php source that is supposed to work with every version from 4.0 to 5.x ? nope ? give it a try, i'm sure you will fall off the fgging chair.

      i suggest you use something else, use python, use ruby, if you need to kiss your bosses ass you might even use java but keep your fingers away from php while you can.

  • Did you look at the PHP 6.0 codebase ? (Score:4, Interesting)

    by Gopal.V ( 532678 ) on Friday November 25, 2005 @11:21AM (#14113093) Homepage Journal
    Sometime back, I pulled out the CVS HEAD [php.net] and tried to hack on top of it. Needless to say it looked alien, with all the hash tables walking around with unicode all around. Php 5.1.xx is only a small step, 6.0 is going to really come crashing down.

    I'd like to take this oppurtunity to complain about __autoload in PHP5. It is one functionality which I find tremendously inconvenient when coding something like APC [php.net]. File inclusions were never supposed to be that dynamic, it ends up with different compilations of the same file for different places it is included in (apparently some [php.net] are still fighting).

  • Are there any good (shared) hosting companies that support PHP 5(.1). Most of the ones out there seem pretty old in the stuff they support, with Apache, 1.3, a 2.4 kernel, running mysql 4, and php 4. Are there any good hosts out there that run new software? I know the old stuff is reliable and works, but sometimes it would be nice to have hosting with cutting edge tools, when stability doesn't matter so much.
  • If anybody is interested in what is coming up in PHP6 you can read an overview here [corephp.co.uk]. Looks like the main push of the next release is to stop people coding things wrong (by depending on register globals and magic quotes). Oh and the small thing about adding Unicode support. Unfortunately this will probably mean a slower adoption than PHP5 as it is likely to break popular scripts (such as forums, blogs etc) which will mean that Hosting Companies are unlikely to touch it till the script writers update their s

  • I here lot's of bickering about PHP 5 ... (Score:5, Insightful)

    by Qbertino ( 265505 ) <moiraNO@SPAMmodparlor.com> on Friday November 25, 2005 @12:27PM (#14113426)
    ... still having no namespaces and lacking in full-blown OOP and all.

    So what?

    PHP is the web generations basic. No more. But no less either.

    Given that loads of very usefull webapps out there are built in PHP
    I'd say the criticisim is mostly inadequate whining. If PHP doesn't
    cut it for your job, take something else. No big deal.
    • Since when has the "If you don't use it, stop complaining" attitude been acceptable? I don't use Windows, but I'm constantly pointing out its faults to people so they're less likely to get infected and have their computer send out spam. I don't smoke, but I'd rather point out the dangers of smoking to someone than let them cut ten years off their life.

      A while ago, I tried writing my own blogging system using PHP, because it would be easy to find someone to host me. I kept having to look things up (isnull or
  • Now that PHP is popular it is undergoing something of an identity crisis. Rasmus said it was an answer to "the web problem", a very simple answer. A "right to the point" approach, terse rather than elegant.

    But as more "serious" developers pick it up, more "serious" features are requested.

    The fact is, if you're flexible you can build whatever you need in PHP4. It may not always be the way you prefer to code, but you can do it.

    PHP is what it is. And it won't appeal to everyone. Fortunately there are many othe
  • Strange how this bug [php.net] doesn't even show up on a search, but punching it in manually brings it up, and google shows you where it is.

    Apparently the ticket hasn't been touched since it was reported 16 months ago.

  • PDO (Score:2)

    by porneL ( 674499 )

    PDO [php.net] is the first API/extension in PHP that looks like it was designed before writing.

    That's big step away from MySQL and magic_quotes mess.

  • Who to emulate today? Perl? Java? C++? (Score:3, Interesting)

    by theolein ( 316044 ) on Friday November 25, 2005 @10:36PM (#14116295) Journal
    I started off doing web coding in PHP 3 years ago, and was even pleasantly pleased when PHP 4 came out as it was a real, practical improvement over PHP3, especially as regards sessions and form data. Since then, I've learnt Java, ASP, Perl and Cold Fusion and started on Ruby. (and C/ObjC for native development)

    Today, after not having done any PHP for about two years, I took a look at the PHP 5 documentation.

    I was appalled.

    Back when I started learning Perl, many of the apparent idiosyncrasies in PHP made sense such as the $syntax, multiple variable assignation, string concatenation and others. PHP had made a simpler version of Perl (automatic dereferencing, yay!). Then, when I was reading through the docs I noticed that PHP5 was doing its utter best to ape the functionality of Java (OO, exceptions, collections, interfaces, reflection, overloading, overriding etc) with the syntax of C++ (:: for static members, -> for virtual methods) but with the same loosely typed variables (Just ask yourself when looking at code you've never seen exactly what type does that unknown function return) and no namespaces (Perl, Java and C++ all have this in some form or another) and a huge array of functions that has no consistency whatsoever.

    So, in essence, we have a language that is a mix of Perl, Java and C++ but with no real innovation of its own, unlike Python or Ruby, both of which are extremely consistent and remain true to themselves. Even lowly Javascript is far more consistent than PHP.

    There is no way that I will code or design a large webapp in PHP. I had to debug a fairly complex one recently and it was a nightmare. I think I'll wait another few years and look what PHP6 turns out to be.

Slashdot Top Deals

Intel CPUs are not defective, they just act that way. -- Henry Spencer

Close