Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
PHP Programming

PHP 5 Beta 1 398

Posted by michael from the php-is-good-for-you dept.
Sterling Hughes writes "The PHP development community is proud to announce the release of PHP 5 Beta 1. Downloads are available in both source and binary form (for Windows users). A full list of changes is available in the ChangeLog. Some of the new features include much improved OO support, completely revamped XML support, and the default inclusion of SQLite."
This discussion has been archived. No new comments can be posted.

PHP 5 Beta 1 More

PHP 5 Beta 1

Comments Filter:

  • They pulled MySQL out! (Score:5, Interesting)

    by baptiste ( 256004 ) * <mike@baptis[ ]us ['te.' in gap]> on Sunday June 29, 2003 @05:00PM (#6326536) Homepage Journal
    Check this:
    Due to issues surrounding the MySQL 4.0 license, the MySQL are no longer bundled with PHP. For more information on these licensing changes, please refer to the MySQL Licensing Policy.
    Wow - that's not a smart move. I guess this is a GPL (MySQL) vs Apache (PHP) license issue? Anyone have more details?

    • Re:They pulled MySQL out! (Score:5, Informative)

      by CausticWindow ( 632215 ) on Sunday June 29, 2003 @05:07PM (#6326569)

      Check this thread [google.com] on Google groups.

      • Re:They pulled MySQL out! (Score:5, Insightful)

        by baptiste ( 256004 ) * <mike@baptis[ ]us ['te.' in gap]> on Sunday June 29, 2003 @05:12PM (#6326592) Homepage Journal
        Ah - well man they need to be clearer about it - the phrase makes it sound like they pulled out MySQL support. The Changelog mentions the library - but even it is really brief. I always thought PHP used your local libraries anyway - I didn't realize it came with them in 4.x
        • I am pretty sure that PHP 4 comes with a MySQL client library, and it is enabled by default during 'configure'.

          In FreeBSD Ports, it compiled the MySQL client package and uses it instead.

      • The thread mentions somebody at mysql is working on a exception to their license to all PHP to continue to bundle the mysql library extension or whatever. I would hope it gets resolved by the final PHP5 and even if not, most distros like Redhat will probably have the RPMs set so this isnt an issue anyways.
      • I don't know whether to flame you or thank you for leaving "hl=no" in that URL. I guess I should thank you, since figuring out why Google was assuming I was Norwegian was very instructive!
    • what's so difficult about using your own mysql installation? this refers to the bundled libraries. aside from changes mysql has made to 4.1, this is a non-issue.

      maybe this will get them to included a bundled version of postgres

      • But how? (Score:3, Insightful)

        by yerricde ( 125198 )

        what's so difficult about using your own mysql installation?

        How do I tell binary PHP to use the installed binary MySQL?

        Please read this comment [slashdot.org] before replying with such an answer along the lines of "compile it yourself".

    • For those using a Unix or Unixlike system there is also UnixODBC. [sourceforge.net]

      Problem solved.

      Its better software engineering wise to use layer with ODBC or something similiar to access your database. Changes to your database will not require whole rewrites. Also you can host the database on a different server other then your web one.

      I consider myself an amuture database programmer so feel free to correct me if I am wrong regarding something like ODBC to connect to a remote server. I think Oracle has some proprietary

      • Re: Just use PEAR/DB (Score:5, Informative)

        by PizzaFace ( 593587 ) on Monday June 30, 2003 @04:22AM (#6329148)
        Instead of ODBC, you'd be better off using the pear/db [php.net] module as middleware. It supports more databases (mysql, odbc, sqlite, pgsql, etc.) and if it isn't the future standard for database access in PHP, something like it will be.

        I've been using PHP's built-in (until now) MySQL functions, because they're faster than pear/db, but this licensing dust-up has convinced me that portability among database vendors is worth a performance hit. And the pear/db module is getting increasing attention and is likely to get faster.

  • Improved OO! (Score:4, Funny)

    by Anonymous Coward on Sunday June 29, 2003 @05:00PM (#6326540)
    That's right, now you can say class { @P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{
    @p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q *=2) +=$f=!fork;map{$P=$P[$f^ord
    ($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[ P.]/&&
    close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];slee p rand(2)if/\S/;print }

  • Turning into Java? (Score:5, Interesting)

    by alannon ( 54117 ) on Sunday June 29, 2003 @05:02PM (#6326544)
    Take a look at the OO changes page. The syntax seems to be converging with Java. I find this amusing in some ways.

  • Problems with newer versions (Score:5, Insightful)

    by Sanity ( 1431 ) * on Sunday June 29, 2003 @05:04PM (#6326555) Homepage Journal
    I recently developed a number of sites in PHP and ran into serious problems when it became clear that most hosting providers use older versions of PHP, and are scared to death to upgrade lest they screw things up for their existing users.

    The PHP people need to provide ways that people can upgrade the versions of PHP on their system such that they can be reasonably sure that existing users aren't suddenly going to find their sites don't work.

    • There's no problem running different versions of php on the same webserver. We're running php 3 and php 4 here, without any problems.

      • There's no problem running different versions of php on the same webserver. We're running php 3 and php 4 here, without any problems.
        The issues I encountered were with two different versions of php 4.

    • Re:Problems with newer versions (Score:5, Informative)

      by larry bagina ( 561269 ) on Sunday June 29, 2003 @05:15PM (#6326601) Journal
      I agree. Even though there are huge differences between version 3 and version 4 (and now version 5), there are also lots of differences between minor versions -- stuff like new functions, changes to how functions work (beyond just bug fixes), etc. Nevermind that there are hundreds of optional libraries and setup parameters, making every installation unique.

      If you're doing a non-trivial php site, and trying to make it work with different versions of php (osCommerce [sourceforge.net], for example), you end up having to rewrite many functions yourself to make sure they work consistently.

      I like PHP, but it suffers from an "incrementalism" design approach. Some stuff really needs to be rethought, and I think PHP 5 is on the right track to doing that.

      • Re:Problems with newer versions (Score:5, Insightful)

        by Sanity ( 1431 ) * on Sunday June 29, 2003 @05:24PM (#6326642) Homepage Journal
        If you're doing a non-trivial php site, and trying to make it work with different versions of php (osCommerce, for example), you end up having to rewrite many functions yourself to make sure they work consistently.
        Absolutely, this is exactly the experience I had.
        I like PHP, but it suffers from an "incrementalism" design approach. Some stuff really needs to be rethought, and I think PHP 5 is on the right track to doing that.
        I hope you are right, but right now I am more concerned about how to deal with differences between different PHP4 versions - it is immensely frustrating to inadvertantly use a function only to discover that it doesn't exist on your new ISPs version of PHP (and of-course they won't upgrade for love nor money lest they upset their other users).

        Someone involved in PHP needs to take a cold hard look at this issue and figure out how to tackle it head-on, or they will find that with each new version, people take longer and longer to take advantage of new features which will cause PHP to stagnate.

        With Java, at least I know for a fact that some Java 1.1 code will work with Java 1.4 and as a result most ISPs keep their Java versions quite up-to-date.

        Until the PHP team treat lack of backward compatability as a bug, this problem will persist.

    • On a shared server where php is compiled as mod_php all users would share the same version. The solution is to also compile different versions of php as a cgi, then it is up to the user to choose which version to use.

      php422.cgi php433RC1.cgi php500B.cgi

      you get the idea :)

      • Kinda kludgey (Score:3, Informative)

        by Sanity ( 1431 ) *
        There are good reasons that ISPs want to use mod_php - and using your proposed solution these benefits are lost.

        If there was some way that you could allow the user to have multiple PHP versions all being used as Apache modules where the user could select the one they want using their .htaccess file, that would be a possible solution.

        Of course, the real solution is for the PHP development team to take the issue of backward-compatability more seriously then they clearly do at the moment.

        • Re:Kinda kludgey (Score:4, Insightful)

          by elbobo ( 28495 ) on Sunday June 29, 2003 @07:20PM (#6327219)
          If there was some way that you could allow the user to have multiple PHP versions all being used as Apache modules where the user could select the one they want using their .htaccess file, that would be a possible solution.

          To my knowledge this is easily doable, and often done. Although I've never properly looked into it (I keep as far away as possible from virtual hosted environments where this would make sense), I believe the idea would be to compile apache modules for each different version of php you wanted to support, LoadModule each one in in your httpd.conf, then bind each one to a specific file extension (.php3, .php4, etc).
      • One of the reasons to use PHP or ASP over CGI is speed.

        Both PHP and ASP are compiled and linked directly to the webserver daemon. CGI uses an interface and the engine is not loaded directly with the web server. This makes it alot slower and you lose all the benefits of what php has to offer.

    • Re:Problems with newer versions (Score:5, Interesting)

      by Motherfucking Shit ( 636021 ) on Sunday June 29, 2003 @05:30PM (#6326682) Journal
      The PHP people need to provide ways that people can upgrade the versions of PHP on their system such that they can be reasonably sure that existing users aren't suddenly going to find their sites don't work.
      The only major compatibility issue that I can think of between, say, the 4.1 branch and the 4.3 branch is that register_globals defaults to 'Off' in newer versions. If you leave it that way after installing, then yes, a lot of older scripts will break. Most of the shared/virtual hosting providers I've had to do script installs on, which have actually upgraded their PHP versions, just installed 4.2x or 4.3x and then manually turned register_globals back to 'On' in the php.ini file.

      To the best of my recollection, there isn't much else that's not backwards-compatible. Even where functions have been renamed (e.g. socket_get_status), the old function names still work, and while deprecated, they don't seem to be going anywhere soon. I have no trouble digging up stuff I wrote back in '99 or 2000 and getting it to work under PHP 4.3; though I do have to enable register_globals in those cases.

      Only problem I ever ran into with PHP where stuff quit working after an upgrade was on a test Apache2 server. It turned out to be a bug related to posted form data. I wouldn't use Apache2/PHP on a production server yet anyway, though; and 1.3.27 still gets the job done. I haven't had time to play with PHP5 yet, so I'm not sure what the differences are in that version.

      I agree at the surprising number of hosts who simply haven't updated, though. There are a lot of hosts still running 4.1x, and even (yikes) 4.06, who just won't upgrade for whatever reason. I do most of my coding these days on 4.2 or 4.3, and have run into plenty of belligerent hosts who refuse to upgrade from a two-year-old release. Typically I just have my clients move to a better host; the providers who don't stay reasonably with the times will eventually figure out that it's hurting their bottom line.
      • To the best of my recollection, there isn't much else that's not backwards-compatible
        To an ISP fearful of bringing his customer's websites down, that kind of assurance is simply useless. He needs a guarantee of backward compability before he is going to upgrade PHP - and the PHP development team simply don't provide anything close.

  • OO support (Score:2, Funny)

    by Anonymous Coward
    I just want to know when they're going to add OO support to as [gnu.org].

  • Yeah Yeah... (Score:3, Interesting)

    by Second_Derivative ( 257815 ) * on Sunday June 29, 2003 @05:10PM (#6326581)
    It's still lumped into a great big inconsistent namespace

    It's still made by a for-profit company who hobble the product in order to not cut into their profit margins too much (Hello? Zend Cache? Optimiser? Compiler? Everything's free in PHP-Land, for a small fee in PHP-Land...)

    I don't mind so much the fact that you can't have servlet-like objects which handle entire sections of your URLspace (as opposed to one URL -- how very un-spider-friendly. Most choke on a ? in a URL and rightly so) and remain persistent (allowing you to do funky stuff like ... pool database connections maybe? no, mysql_pconnect() doesn't count. Oh, and what's with this SQLite thing? had a bit of a fallout with the MySQL team?) ... because that kinda defeats the point of PHP anyway.

    But come on. Fellas. PHP: Hypertext Preprocessor is the name. Not PHP: Application Server. If those first two issues were fixed it might actually make a seriously powerful hypertext preprocessor. That's something it's reasonably good at. But at the moment it's some sort of bastard preprocessing language run amok that people use to write whole web applications with and other stuff Nature never intended. Perl's got an awful syntax and a total lack of convention (and mod_perl is really byzantine), and I really really really really ..... (x47) really want to like Python, but it's not re-entrant and has a big interpreter which makes its threading capabilities into nothing more than a silly joke (and last I checked, efforts to rectify the situation died back in, what, 1997?), so yeah I admit I use PHP for quite a few web devel jobs. But just because everything else sucks more, doesn't mean PHP doesn't suck any less.

    I'm not even sure what my point is anymore. But, I think what I was trying to say was this isn't much. Same stuff is true of PHP as has always been true of it... wake me up when they get round to PHP6. An earlier rant I made comparing Perl to PHP (I think I preferred Perl back then) is here [slashdot.org]. The extended comment history is pretty much the only reason I got a subscription and to be fair I think it's worth the money.
    • PHP is far more capable out-of-the box than any other web language. Plus there are free replacements for much of the Zend such, as the Alternative PHP Cache. Furthermore, what exactly the hell is your problem? Do you have some issue with people trying to put foot on the table, while still giving away the bulk of their work for free. If the Zend team could not work on PHP and related projects fulltime, do you think PHP would be near as useful as it is?
    • You are brilliant. I thought I was the only human being on the planet who noticed (much less GAVE A RAT'S PATOOTIE) that PHP was now controlled by a for-profit entity. Email me some time (jb AT twu DOT net) and I'll gladly host your Web site forever. You rule.

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

      by eadz ( 412417 )
      I don't mind so much the fact that you can't have servlet-like objects which handle entire sections of your URLspace
      You can! Use a PHP file instead of a directory for your DocumentRoot in apache.
      I.e DocumentRoot /var/www/servlet.php
      Now all requests are handled by servlet.php.
  • just glad they have so many mirrors. I was worried the /. effect would have kept me from getting it

  • The obligatory predictions... (Score:5, Funny)

    by UsonianAutomatic ( 236235 ) on Sunday June 29, 2003 @05:15PM (#6326603) Homepage
    1. PHP Sucks, Perl is a much better language.
    2. PERL sucks, PHP does most of the same stuff Perl does but you can still read your own code a week later
    3. PHP isn't a real language, it's just a bunch of wrappers thrown around stuff. PHP sucks.
    4. Who cares about MySQL support, MySQL's not a real database anyway. MySQL sucks. PostgreSQL rulez.
    5. WTF I upgraded to PHP 4.1.2 and all my form submit scripts stopped working. Whats this register_globals crap anyway what a pain.
    6. Continue with language specific criticisms; loose typing, OO not as strong as Java, et cetera.
  • God damn!
    I'm half-way through re-writing our website to remove our dependance on the depreciated register_global_variables stuff which I learned to live with and then was told was a stupid idea.
    I'm hoping they don't break too many other things 'cause being a php beginner, the whole process is a bit of a nightmare.

  • Destructors! Hooray! (Score:2, Insightful)

    by Wuhao ( 471511 ) *
    I have always been very annoyed not having destructors in PHP. PHP5 includes destructors, along with public/private class members. I can't wait for this to be released as a stable version.

  • Final version (Score:3, Informative)

    by InsaneCreator ( 209742 ) on Sunday June 29, 2003 @05:26PM (#6326651)
    So how long until we get the final version?

    I'm currently developing a PHP project with lots of OO code and it's about as plesant as removing your eyes with a rusty spoon (some control structures implicitly copy objects, they don't know how to return references, you can't write $a->getB()->doSth(); ...).

    Improved OO support in PHP5 would be really nice riht now.

  • Yawn (Score:3, Interesting)

    by Anonymous Coward on Sunday June 29, 2003 @05:26PM (#6326653)
    I'm a PHP programmer and I've begun to recognize a pattern in software: when will we see the end?

    Truly, what more can you add to PHP? Why do most software packages continue to add features without actualy providing a subjective goal to strive for?

    For example, in the world of Microsoft(R) Windows we see the same operating system have plastered above it "Where do you want to go tomorrow" and above all "n% faster than previous, more stable, etc." When will the goal of a products feature-list finally be met?

    I know Perl5 accomplished its goals, and then they had an {ap-if-in-ee} to add the RegEx in yet another release of Perl titled Perl6. When will they ever make a product that has a goal? I don't call this competition...I call it beating a dead horse from its grave, like how Intel puts rocket boosters on its crumy brick CPU architecture (Pentium Pro) and adds some more features.

    Look at netBSD; it isn't dying, it's still working on its number-one goal: security.

    Linux is the same way; it stated from an original design and now is being extended. Am I sounding like I expect a new feature to be a new product? I don't think so... GNU/HURD, of which I know many people are skeptics unto, is builind upon its goals of being a Micro Kernel and add some. What if Linux all-of-a-sudden wanted to become a Micro Kernel? What if Microsoft(R) Windows(TM) all-of-a-sudden wanted to become a Micro Kernel?

    The software names, after huge changes to extend their capabilites, are becoming misleading! If you take out a RedHat Linux 5.2 system and compare it with RedHat Linux 8.x, you can't say they are both similar Linux; they are completly different! Sure, it's like comparing apples with oranges on the old and new RedHat, but Kernel-wise the latest Linux Kernel may look completly different and have completly different goals and features than what was hoped for in the verry early Linux kernels. Shouldn't to cause less confusion and more inspiration, they leave the Linux name behind with the old design and all the new stuff that would completly change Linux's software (mechanical?) appearance become known as the new project Herring(TM). I anticipate most of you will reply with "That's why we have VERSION NUMBERS", but hey? You're missing the point.

    Microsoft(R)'s Windows(TM) name isn't describing the project's code name, yet the product's retail names are somthing like 95, 98, NT, 2000, XP. Well, it is honest to say that the NT and 2000 products are similar, 95 and 98 products are similar, and the XP product isn't quite similar to 95 and 98 and 2000, but then there was the fiasco that all the 9x users went out to buy product Windows(TM) 2000 and found they had been tricked by Microsoft that 2000 would be like a 95 or 98. Anyone see my point?

    As for PHP, and perhaps Perl... Does anyone think they should continue calling those products by their initial names AFTER the programming syntax and methodology becomes completly different or non-compatible than they were first designed?

    I'm looking forward to some intelligent answers. Thanks and I'll be a PHP and Perl programmer for a long time to come. d:-)
    • Look at netBSD; it isn't dying, it's still working on its number-one goal: security.

      I think that would be portability. OpenBSD's goal is security.

      You make some fair points. I would have to say that you can't very well expect software to change it's name just because it's evolved. I'm not the same person I was twenty years ago by a long shot but I'm not about to call myself Roger Keith. I don't expect to be exactly the same person in twenty years by I will still be recognisable. Probably.

    • Re:Yawn (Score:3, Insightful)

      by c13v3rm0nk3y ( 189767 )

      ...I've begun to recognize a pattern in software: when will we see the end?

      Well, never.

      Software design is unlike most every other discipline in the world. Your job is never finished until the product is dead. There are always bugs to fix, inconsistencies to remedy. Even the action of fixing bugs will create or uncover new ones. The fact is, if you release version 1.0, by definition you will also have to release version x.y for the entire life-cycle of the product. This also implies that versions ma

    • Re:Yawn (Score:4, Insightful)

      by damiam ( 409504 ) on Sunday June 29, 2003 @11:05PM (#6328154)
      I'm looking forward to some intelligent answers.

      You're new here, aren't you?

    • Re:Yawn (Score:4, Insightful)

      by Hard_Code ( 49548 ) on Monday June 30, 2003 @12:25AM (#6328497)
      "I know Perl5 accomplished its goals, and then they had an {ap-if-in-ee} to add the RegEx in yet another release of Perl titled Perl6."

      Have you even READ anything about Perl6? Any of the apocolypses or exegises? After lots of incremental crud got added in the (very successful) Perl5 series, they are stepping back, rethinking, refactoring, and reimplementing with a very clear and concise goal of optimizing the syntax for the most used cases, as well as fixing known warts. Additionally they are doing this on top of a generic reusable virtual machine, instead of an ad-hoc specific-use interpreter. I don't even like Perl and I realize that Perl 6 is a Good Thing.

  • JSP (Score:3, Interesting)

    by nepheles ( 642829 ) on Sunday June 29, 2003 @05:32PM (#6326690) Homepage

    The will be an interesting battle. JSP and PHP are now broadly identical in syntax and OO implementation. Who'll win? PHP is OS, but JSP has a huge amount of support from corporations.

    I'm betting on JSP

    • Not to mention that Java is the latest buzzword in web applications. Most company executives are completely clueless when you say PHP, but their ears will perk up when you say Java Server Pages. The branding's just not there with PHP. (Related note: I favor PHP a lot more than JSP, but that's just my opinion, for what it's worth)

    • Both (Score:3, Informative)

      by Delirium Tremens ( 214596 )
      Both will win.
      The latest news from Sun is that J2EE 1.5 will support scripting languages. And the reference implementation will be done in PHP.
      If you don't believe, check some of the news site reporting on JavaOne 2003.

  • Advice & Observation (Score:2, Informative)

    by calebb ( 685461 ) *

    Advice:
    The default method of configuring PHP is with the CGI SAPI module (i.e., php.exe); A much better choice (imo) is to configure the CLI SAPI module - all you have to do is build the CLI SAPI .dll (Depending on which webserver you're using - php4apache.dll for Apache, php4isapi.dll for IIS)

    (Also, many websites refer to the two config methods as CGI and SAPI; This is not really correct since CGI *is* a server API. What they really mean is CGI SAPI & CLI SAPI)

    So, why go through the trouble t

    • Re:Advice & Observation (Score:2, Informative)

      by aint ( 183045 )
      This post has some problems as there is no such thing as a CLI dll... In Windows you have two php.exe binaries, the cli in the cli/ folder, and the cgi in the root php source folder. The CLI WILL NOT work with the web server, it's a Command Line Interface.

      Regarding the DLL, you are referring to SAPI modules, not CLI. And yes, using them is preferred (although depends on who you ask :) but this topic is not related to this thread on the PHP 5 Beta.

  • XML transformation pipeline (Score:3, Interesting)

    by graveyhead ( 210996 ) <fletch@@@fletchtronics...net> on Sunday June 29, 2003 @05:49PM (#6326768)
    I have always wanted PHP to have an XSLT based transformation pipeline, similar to what Apache Cocoon [apache.org] has. I would like to be able to write source documents in XML, arbitrarily transform XML into HTML and PHP, interpret the PHP, possibly transform again and finally output the results. I know I could build this top-down from within a single PHP document, but I'd like this pipeline to be a part of the mod_php distribution, with the .XML file extension mapped to the pipeline processor.

    Anyone wanna help me build it?

  • Breaking MySQL support - what *sses (Score:4, Interesting)

    by wytcld ( 179112 ) on Sunday June 29, 2003 @06:20PM (#6326960) Homepage
    Considering that I've been a Linux/Apache/MySQL/PHP developer since they each were available, it's just disgusting that they're making it harder to support MySQL at a time when LAMP is a recognized contender against Microsoft. I am not going to fscking rebuild a bunch of sites' dbs and recode MySQL-specific PHP code just because the GPL gives these guys a rash. Certainly when PHP was under Rasmus's authorship and control, he was never this sort of jerk.

    I'm not saying I can't take the trouble to link in MySQL libraries, just that there's no good excuse for the PHP folks to make me - and thousands of others - go to this trouble. They could, if nothing else, distribute their nonGPL PHP, plus a GPL kit that adds MySQL support, if they're too scared that the GPL will give them cooties.
    • They haven't broken the MySQL extension, and it won't be any more difficult to support. All distributions will still be able to ship binary packages that link with MySQL. You won't need to compile or link anything yourself, unless compiling PHP is something you like to do anyway.

      Stop being so dramatic.

    • Its would mean breaking MySQL's GPL license if PHP bundled current version of MySQL client libraries.

      This because FSF claims that Apache and PHP licenses are not GPL compatible, thus linking against those is not premitted. It does not help that MySQL AB has chosen to change their client library license from LGPL to GPL after release 4.0 of MySQL

      Nothing to do with the PHP development team really.

  • FREE!! -- PHP Encoder and Cacheing -- FREE!!! (Score:5, Informative)

    by Anonymous Coward on Sunday June 29, 2003 @06:21PM (#6326968)
    Yes yes.. To sooth all the scalp scratching surrounding PHP and FREE (quality) cacheing and encoding look no futher than

    MMcache - http://www.turcksoft.com/en/e_mmc.htm

    It's only a split second .001 slower than zend (faster than PHP Accelerator) and it FREE! Did I mention it works with Zend Optimizer , Zend Encoder and it can also Encode (protect) PHP files?

    I'm too damn good to you people! ; )


    PS: PHP makes programming fun again. Thats why people like to use it. Simple really.

  • PHP 5 Documentation update (Score:4, Informative)

    by aint ( 183045 ) on Sunday June 29, 2003 @07:20PM (#6327223)
    PHP 5 isn't really documented in the PHP 5 manual yet as there are still a few features on the move, and new features to come, but here's a list of PHP 5 related articles and presentations:

    Faq: Where can I get more information about PHP5? [faqts.com]

    Enjoy!

  • PHP fragmentation, lack of cohesion (Score:5, Insightful)

    by theolein ( 316044 ) on Sunday June 29, 2003 @07:45PM (#6327369) Journal
    I've been using PHP since the 3.0 days and always loved it's speed in development for small dynamic sites. There is truly nothing simpler (IMO) for small sites. Why on earth did PHP ever become so popular as compared to Perl/CGI? It was the simplicity.

    Most people accepted the changes from PHP3 to PHP4 without complaining as PHP4 brought simple session support and other needed features. Thousands of developers wrote scripts for small pages and uses, and those scripts got placed on help sites etc all across the web.

    The changes above 4.06 where register_globals got turned off by default and -from a simple beginners point of view- to 4.2 where a stunning array of new arrays were added for sessions, post and get variables. Those things broke almost everybodies scripts, and all those thousands of scripts across the web no longer worked as is. Due to this a lot of ISP's no longer upgraded regularly.

    At the same time PHP started jumping on the "web application" gravy train, something for which PHP with it's awkward OO support (no automatic calling of parent constructors etc), lack of stateful session support etc was not designed to do. The makers of Zend decided to go the whole hog and redo OO support, add hundreds of seldom used features but ignore problems with backward compatibility and language simplicity.

    Congratulations. Now we have a language that is slowly matching JSP in complexity (as all the 1337 "application developers are saying"), is nowhere nearly as well integrated in in true web applications as JSP is (great, it can support Java classes, how many will simply use Java then?) and is leaving the roots of it's enormous success behind.

    Take a lesson from Perl's "failure" in web site popularity. Don't keep on adding features for the love of it.

Slashdot Top Deals

Our OS who art in CPU, UNIX be thy name. Thy programs run, thy syscalls done, In kernel as it is in user!

Close