Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
PHP Programming Upgrades

Changes In Store For PHP V6 368

An anonymous reader sends in an IBM DeveloperWorks article detailing the changes coming in PHP V6 — from namespaces, to Web 2.0 built-ins, to a few features that are being removed.
This discussion has been archived. No new comments can be posted.

Changes In Store For PHP V6

Comments Filter:
  • by i.of.the.storm ( 907783 ) on Sunday May 11, 2008 @06:00PM (#23371976) Homepage

    I would think swapping mysql for XML would make things run slower on the whole, especially large databases, but I'm not an expert in that field. XML and mysql really serve different purposes, and I don't think replacing mysql with XML would be a good idea for the vast majority of use cases.

    Oh, and what happened to the spiffy discussion2 stuff? Now comments open in new pages again and I can't reply inline. What's up with that?

  • by truthsearch ( 249536 ) on Sunday May 11, 2008 @06:01PM (#23371982) Homepage Journal
    Especially since most of the "new" features are either already available or will be included in v5.3. There's literally nothing new here except better Unicode support.
  • Re:Major version? (Score:3, Insightful)

    by eebra82 ( 907996 ) on Sunday May 11, 2008 @06:07PM (#23372030) Homepage

    I don't see why this is a major update (5 => 6).
    If I had a software development business, I would do this if I wanted to push a release a little extra. People don't care as much about decimals as much as they care about entirely new release numbers.
  • by cheater512 ( 783349 ) <nick@nickstallman.net> on Sunday May 11, 2008 @06:10PM (#23372050) Homepage
    No.
    XML is a format designed to transmit data between machines, not for data storage.

    Imagine a 50 gigabyte database. I have one.
    Now imagine the same database in XML.
    The size would explode and you suddenly have to seek the entire db for a simple select.
  • by bcat24 ( 914105 ) on Sunday May 11, 2008 @06:17PM (#23372124) Homepage Journal

    There's literally nothing new here except better Unicode support.
    True, but better Unicode support is a very major feature in and of itself. Let's face it, writing a Unicode-enabled Web application with PHP 5 is like hunting wildebeests with a BB gun. It's possible, but it sure ain't easy.
  • by gandhi_2 ( 1108023 ) on Sunday May 11, 2008 @06:18PM (#23372138) Homepage
    It was to protect you from the O'Malleys and O'Connors. The PHP framers were obviously fans of Mel Brooks' film, Blazing Saddles: "We'll take the niggers and the chinks but we don't want the Irish". Or I'm missing something.
  • by MROD ( 101561 ) on Sunday May 11, 2008 @06:26PM (#23372186) Homepage
    Many commercial PHP-based systems are only now just changing over to PHP5 from PHP4. (Yes, I know...)

    That's the way life is, I'm afraid. Most people who are depending upon these sites and software have no control over the vendors and definitely don't have the ability of fixing the code themselves.

    Changing the API so greatly and so often in a non-backwardly compatible fashion does cause genuine problems.. and hosting sites can't afford to support multiple versions. Well, not unless they charge their customers too higher price for hosting their pages.
  • by MightyMartian ( 840721 ) on Sunday May 11, 2008 @06:26PM (#23372188) Journal
    I simply can't wait for an even bigger php.ini file to support disabling and re-enabling of deprecated functionality. I've spent several evenings over the last few weeks on a contract to clean up some really bad PHP code, and a good fraction of that time has been spent actually getting a test bed up and running, trying to match the Win32 PHP 5 install I'm forced to work with the Linux PHP4 install on the production server. More than ever before I'm convinced that PHP is the worst major language ever invented, and I'll wager PHP6 only makes it worse.
  • Real change (Score:3, Insightful)

    by Anonymous Coward on Sunday May 11, 2008 @06:33PM (#23372246)
    Make it like a modern language.

    Change . (string concat) to +

    Change -> (pointer-to-member operator) to .

    Done. Huge productivity increases.

    Thank you.
  • by thetoadwarrior ( 1268702 ) on Sunday May 11, 2008 @06:35PM (#23372264) Homepage
    Um, no it's not. It's only downfall is that it's too easy to do powerful things so idiots make dangerous code.

    That is not the language's fault. Not everyone wants or needs a JBoss server or something equally silly for their website. PHP is still very good. Safe programming in PHP just needs to be preached more to the new users of PHP and some of the self taught people who perhaps learned off the net from someone else with little experience rather than a book since all books I've seen cover the basics on safety.

    The only thing that annoys me is the fact it's function naming methods aren't consistent. It shows that it's had input from various places without any thought into standardizing things.
  • by robo_mojo ( 997193 ) on Sunday May 11, 2008 @06:41PM (#23372308)
    So does this mean that if you are using magic quotes and you upgrade to PHP6, suddenly you will become vulnerable to SQL injection attack? Wow, I'd consider that to be a major regression, then.
  • by Falesh ( 1000255 ) on Sunday May 11, 2008 @06:42PM (#23372316) Homepage
    Don't be daft, PHP 5 is a solid language and it doesn't take much to learn how to write secure code. If you view it from a rookies point of view it could be dangerous, but that doesn't magically make the language crap in the hands of more experienced developers.
  • Re:Major version? (Score:5, Insightful)

    by Splab ( 574204 ) on Sunday May 11, 2008 @06:43PM (#23372320)
    "and a bunch of stuff removed"

    The stuff addressed are some of the widest security holes. On top of that the old way of programming PHP and most guides out there encouraged the usage of these bad functions, getting them totally removed is a huge step forward.
  • by FooAtWFU ( 699187 ) on Sunday May 11, 2008 @06:49PM (#23372368) Homepage
    That's not its only downfall. Its other downfalls include some miserable organization and bloated core, though much of this may be attributed to lack of namespace support - which is being remedied, but it's a bit late. There's still a lot of package_name_prefix_with_function_name functions, and I don't see them going away soon.

    Beyond that, and the pervasive "make it easy to do the WRONG thing" un-philosophy, I still haven't heard about it getting lexical scope, closures, and anonymous functions. Of course, this only matters if you're a good programmer (as opposed to merely a Decently Adequate one).

  • Re:Major version? (Score:3, Insightful)

    by WK2 ( 1072560 ) on Sunday May 11, 2008 @07:02PM (#23372444) Homepage
    They are removing some things. According to Splab, above, removing these things is a huge step forward. More importantly, removing things should always be a major release. They are breaking backwards compatibility with everything that uses the things that they are removing.
  • by KnightMB ( 823876 ) on Sunday May 11, 2008 @07:08PM (#23372496)

    Unfortunately, everyone has already realized that PHP is an insecure, featureless piece of crap. Real web developers have moved onto other platforms, or stuck with Perl.
    I think I hear this every time someone has been hurt by a buddy who was able to code circles around them in PHP while they struggled in Perl. Real web developers use every tool at their disposal, not just Perl or PHP only. Your statement alone shows the conceit you have about your own skills as compared to everyone else that makes a living doing web development, apparently much more successfully than you.
  • by njcoder ( 657816 ) on Sunday May 11, 2008 @07:40PM (#23372668)

    Yeah. What happened in 2005 to make it plateau like that?
  • by pembo13 ( 770295 ) on Sunday May 11, 2008 @08:09PM (#23372822) Homepage
    That's pretty unfair circumstances under which to judge any language.
  • by moderatorrater ( 1095745 ) on Sunday May 11, 2008 @08:11PM (#23372834)

    and happens to integrate very well with HTML
    Yes, like regular expressions happen to be good at finding string patterns. PHP is good because it is first, foremost, and almost exclusively a web scripting language, which means you get really like features like super globals, HTML embedding, loose typing, great escaping functions, etc. Most other languages try to be all things to all people, but PHP has a focus and it does it pretty well.
  • Comment removed (Score:2, Insightful)

    by account_deleted ( 4530225 ) on Sunday May 11, 2008 @08:38PM (#23373004)
    Comment removed based on user account deletion
  • by CastrTroy ( 595695 ) on Sunday May 11, 2008 @09:14PM (#23373252)
    I'm with dreamhost, and I still have the option to switch my domain over to 4.4.x, although I'm currently running on 5.2.x. I don't see why a webhost with a large number of customers, couldn't support multiple versions of PHP, especially if there was a large number of customers (at least 10-15%) using that particular version.
  • by mini me ( 132455 ) on Sunday May 11, 2008 @09:44PM (#23373452)

    What makes PHP nice is that, language-wise, it is basically C plus a subset of C++ wrapped up in a scripting language.

    That's the problem with PHP. It requires all the hard work of writing C-like code, without any of the benefits that one might chose C for.
  • by larry bagina ( 561269 ) on Sunday May 11, 2008 @10:00PM (#23373540) Journal

    PHP doesn't have any weird syntax like Perl regular expressions---you can do Perl regex, but it is neatly encapsultated into proper strings the way it should be.

    Interesting example of PHP superiority. Perl regular expressions are delimited with / (or another character) because it's part of the language syntax. But if your regular expression is encapsulated in a string, there's no longer a need for it (which would simplify things since you don't need to escape it). Yet the pcre functions use a delimiter. Monkey see, monkey do. Without knowing why.

  • by The MAZZTer ( 911996 ) <.moc.liamg. .ta. .tzzagem.> on Sunday May 11, 2008 @10:43PM (#23373816) Homepage

    I hope they have some sort of protection against that; specifically, if you have magic_quotes turned on in php.ini (or whatever the linux equivilant is) PHP should refuse to start, perhaps logging an error message which explicitly tells the webmaster magic_quotes is no longer supported, and that it must be turned off, and the possible consequences of using old scripts designed to work with magic_quotes on. This forces the webmaster to actually go into the config file and turn magic_quotes off, and if they didn't fix their scripts or tell their clients to do so it's their own fault. And of course if they have badly configured security, this could mean even bigger consequences, but this is possible even with magic_quotes, depending on the scripts and holes in them. A separate message for safe_mode (also scrapped for 6) would also put the consequences of not properly setting up user permissions and the permissions of the account running the web server in big bold letters.

    If they do something like that, no-one can really say they weren't warned, since a webmaster would actually have to go in and turn it off, and would be told exactly what could happen if they don't take the proper steps.

    A friend of mine is happy these two settings are being killed, as am I. It can be tough to code with the restrictions put in place by safe_mode and magic_quotes, which as I understand are just to cater to lazy irresponsible server admins and lazy irresponsible programmers, respectively. Although safe_mode does serve a legitimate purpose since currently all scripts, regardless of which user owns it, are run under the permissions of the webserver user. This strikes me as more fo a webserver problem than a PHP problem, though. Not sure how much the PHP team could do... except for maybe safe_mode.

    To end my little rant, here's a helpful bit of code pulled from the pastebin source (GPL) to combat magic_quotes in _GET and _POST and _COOKIE:

    // magic quotes are anything but magic - lose them!
    //
    if (get_magic_quotes_gpc())
    {
    function callback_stripslashes(&$val, $name)
    {
    if (get_magic_quotes_gpc())
    $val=stripslashes($val);
    }


    if (count($_GET))
    array_walk ($_GET, 'callback_stripslashes');
    if (count($_POST))
    array_walk ($_POST, 'callback_stripslashes');
    if (count($_COOKIE))
    array_walk ($_COOKIE, 'callback_stripslashes');
    }
  • Almost.. (Score:3, Insightful)

    by encoderer ( 1060616 ) on Sunday May 11, 2008 @11:17PM (#23374040)
    ...He took the "contract." Nobody was forced.

    But his post is inane.

    Isn't it about as basic as it gets that code (outside of Java) should be developed on the same platform that it will ultimately be deployed upon?

    If he had done that, all he'd have needed to do was get a copy of the binary as compiled for use on the production server, and their php.ini. Install, copy in the php.ini, and he's up and running in an environment identical to the Prod server.

    Barring that, if he'd had gotten their php.ini anyone w/ any PHP experience would be able to see what non-std components were included, and the version everything is running at. Download it, compile it, install, and copy-in the php.ini.

    If he's spending a "good fraction" to get a "test bed" then he really should stick to tech support or network administration or whatever he's done over the past few years full time for a living.
  • by TheLink ( 130905 ) on Sunday May 11, 2008 @11:59PM (#23374294) Journal
    But shouldn't you be using mysql_genuine_advantage_escape_string() instead ;).

    It's stupid stuff like that and "Magic Quotes" that make PHP a sad joke.

    Magic Quotes = mixing input layer filtering with output layer filtering = bad. You tend to get data corruption amongst other things.

    Then there's addslashes and friends.

    PHP: "Making The Wrong Ways Easy, and The Right Ways Hard".

    Oh well, I guess php6 is where they are finally trying to do things right now.

    All the pain is because php coders were doing things terribly wrong in the first place. Don't forget the PHP devs were encouraging them to do things wrong for years.
  • by SanityInAnarchy ( 655584 ) <ninja@slaphack.com> on Sunday May 11, 2008 @11:59PM (#23374298) Journal

    PHP doesn't have any weird syntax like Perl regular expressions---you can do Perl regex, but it is neatly encapsultated into proper strings the way it should be.
    Regex is never really going to be readable without a separate course learning that. By the time you know regex syntax, a little extra syntax in your language isn't that bad.

    There's no having to manually re-indent dozens of lines of code because you needed to add another nesting level and whitespace is part of the language, etc.
    And there's no need to do so in any modern programming environment, either. Most text editors these days have ways to re-indent code, uncomment/comment keyboard shortcuts, etc.

    It's just a really clean, lightweight OO language that's exceptionally easy to learn
    Easy to learn if you already know HTML, I suppose. But where's my actual, interactive PHP shell that I can play with while I'm learning the language?

    OO? Only recently.

    Clean? Not even close, not when you've used a real OO language.

    and happens to integrate very well with HTML.
    So does everything else, now. I'd argue Ruby is actually better [hamptoncatlin.com] at this than PHP.

    Don't get me wrong, PHP has plenty of weak points when it comes to performance
    My language of choice right now is Ruby, so I don't really care about that.

    availability of modules to do various obscure things
    Considering the amount of crap built-in to the language, I doubt that's a huge stumbling block, either. I like CPAN, but it does help when the language itself is clean enough that I'll happily write a library of my own. But most that I'd need to do with a C library has bindings everywhere I really want to do it.

    mainly because it isn't a kitchen sink like Perl
    I think Perl has too many built-in functions, available everywhere, completely un-namespaced, compared to Ruby.

    But you know what? Perl has a little over two hundred functions in the main namespace. PHP has a little over three thousand, according to this page. [www.tnx.nl]

    So, it may not have the kitchen sink in the syntax, but it has the kitchen sink, the bathtub, the plumbing, and the neighbor's shower in the core library.

    Finally, I call BS on this:

    Almost any code written in C (or C++ without templates/exceptions/other icky stuff) can be trivially ported to PHP by replacing the type names with "var" and adding dollar signs in the right places. (I'm exaggerating slightly, but not much.)
    Is there a language, other than Python, that this isn't true of, for very simple, "Hello World" or "My first HMAC implementation" examples? Sure, the rules would be different, but dropping all the type declarations (swapping for "var") and adding dollar signs is significant.

    Oh, and does PHP support structs? What about function pointers? I doubt it's "almost any code". It's easy when you understand both C and PHP, but again, I assert that's true for many languages, particularly popular web scripting languages.
  • Re:Almost.. (Score:3, Insightful)

    by cayenne8 ( 626475 ) on Monday May 12, 2008 @12:35AM (#23374518) Homepage Journal
    "Isn't it about as basic as it gets that code (outside of Java) should be developed on the same platform that it will ultimately be deployed upon? "

    You're still in school or new to the real world, arent' you?

    :-)

    Of course it should be that way...but, often out there, you run into just this situation. The mgmt. wants a change or something done, but, they don't wanna buy new hardware, etc....

    It sucks, but, I've run into systems where the dev. and prod. are on different platforms...and this isnt' just because of cheapness, in the govt. contracts...sometimes one company wins the dev. part of the contract and a different company has the prod. I've seen this where the system is developed and tested in a win environment, but, is to be deployed to a unix environment, yet, they can't understand the inevitable problems that have to be ironed out, but, no time for this was scheduled. And this is on multi-million/billion dollar systems.

    This isn't something that is all that rare.

  • by mcrbids ( 148650 ) on Monday May 12, 2008 @02:56AM (#23375134) Journal
    I've worked with PHP professionally, building a healthy, heavily profitable, and rapidly growing company providing information management services to schools.

    From the simple standpoint of "concept to implementation" - PHP ROCKS. It's very, very fast, requiring little in the way of "planning" and "structuring" while letting the features come out... FAST. It is, bar none, the best RAD environment I've yet worked with. Not that it's the best in every area, but that it clearly has the best balance between features and "gotchas". It has its weaknesses, such as lousy error reporting, but even that can be largely mitigated with a little intelligence in advance. But it really does have a number of key strengths that I leverage to the hilt:

    1) Stability. It just doesn't die. Ever. I've never, ever, ever had a problem with PHP "not working". I don't troubleshoot it. It's there, it works, and I don't sweat it.

    2) Scalability. It's "share nothing" approach makes clusting and random-host selection boil all the way down to a simple session manager. Having 1 or 10 application servers running side-by-side is almost trivial!

    3) Code density = excellent! It's a fairly dense language, meaning that lots can get done in a few lines. Just for giggles, I've written a self-forking, multi-process daemon with a process manager and hundreds of managed children forks performing a deep-level network scan in like 50 lines!

    4) Security. Yes, you heard me correctly. Although you can certainly use PHP "wrong", you can also use it "right". Once you do, you discover that PHP has a number of features that make things like SQL injection and shell parameter expansion a thing of the past. Really. Learn your tools!

    5) Flexibility. You can run it as a module inside Apache. You can run it as a standalone executable. With tools like Ion Cube and PHP-GTK, you can create a cross-platform GUI application without revealing source.

    6) Availability. Any $5/month web hosting company supports PHP, and there are many free ones, as well. You can download a CD, install Linux, and have PHP/Apache up and running in under 10 minutes. There are batrillzions of apps available A LA SourceForge for free. PHP is the most commonly available web development language. And, by no means is it a web-only development language!

    Sorry you can't handle a few quirks in the function names. (so write out a file of wrapper functions - DUH!) Sorry that it's attempts to simplify variable management weren't perfect. Geez. Just code in c and be done with it, why don't you?

    In short, PHP is everything that VB and .NET wished to be, only cross-platform. It's an excellent tool for developing information-processing applications, very, very rapidly. Yes, it has its weaknesses, and nobody's forcing you to use it, and the devs are working on the weaknesses, too. Go use Ruby if it makes you feel good. But PHP works well on Windows, Mac, Linux, BSD, and many others. Seriously: you really can't go too wrong betting on PHP unless you need 3D graphics!
  • by SanityInAnarchy ( 655584 ) <ninja@slaphack.com> on Monday May 12, 2008 @03:30AM (#23375266) Journal

    Personally, I like things like integrated FTP, integrated subversion, integrated unit testing, and, most of all, an integrated server-side debugger w/ all expected function: breakpoint/play/step control, stack and heap manipulation, etc.

    The debugger is the only thing I miss from a "real" IDE.

    Subversion is garbage, of the "at least it's not CVS" variety. There are at least some ten or twenty distributed version control systems out there, at least one of which has got to work well for you.

    FTP is garbage. Use anything else. Yes, anything else.

    These are actually related. I don't really like most of the stuff you mentioned "integrated", as that usually means things like "I have a keyboard shortcut to run unit tests!" Great, but I'm comfortable on the commandline. Let me switch between my editor and terminal easily, and I'll run unit tests, run a development server, and anything else I feel like.

    The other reason is that I can then switch to pretty much anything else without having to switch IDEs. I know just about everything is supported on Eclipse, but "just about" isn't everything. I don't have to choose between Git and Subversion -- I can use bzr, hg, darcs, or really whatever the fsck I want. I don't have to use FTP because it's got the prettiest interface -- I'm just as comfortable with scp -- or, when it makes sense, Capistrano -- I can even use things like KDE's fish GUI for ssh.

    All of these are possible using a text editor, but you need 5 different applications

    Yes, that's the Unix Way.

    and none of it works together.

    Wrong, wrong, WRONG!

    All of it works very well together. On the occasions where it doesn't, I can hack together the glue require reasonably quickly, and be back to being as productive as I was before -- but these cases are also times when an IDE wouldn't be able to work with them at all, and I know a lot more about hacking together scripts (shell and similar) than I do about writing Eclipse plugins.

    Not to mention: INTELLISENSE

    Useless, unless it's linked to documentation. And then, still useless, compared to flipping over to my browser and asking Google, since I probably don't actually know what I want there.

    Not that I would be against having it, but I'm not willing to fire up Eclipse (and burn all my RAM, and still have it be sloppy and inaccurate due to being a dynamic language) just for Intellisense.

    And then there's workspace management, and keeping plugins in sync, and dealing with when plugins go bad -- can't start Eclipse until I figure out which plugin is making it crash, or, more likely, wipe it and reinstall from scratch -- and it'll autodetect the file as the wrong type, so now I have to go fuck with its filetype associations, and set keyboard shortcuts -- whoops, the shortcuts I want aren't there...

    There's a whole new level of bullshit I'd have to deal with if I was using an IDE. I know, I was for awhile.

    and DATA TYPE DISCOVERY! (on a loosely typed language that's a big help).

    If I understand this, it might be a help if I had functions so massive I can actually lose track of a variable, or if you're talking about the whole built-in debugger feature.

    Instead of having to basically memorize or manually lookup class names, method names, and method arguments, I just begin typing the class name, use some arrow keys, and be done w/ it.

    Except that by the time I'm doing that, I probably want to know more about it. For example: Is this indexed from zero, or one? How do I create a has_many relationship with an order clause? Does that have to be a string, or can it also be some other cool data structure?

    Let me know if you find an IDE that can handle Intellisense in Ruby and actually make me more productive.

    Oh, also, a fair amount of what you're doing probably should fit in your head. If you're not doing PHP and needing to know things like mysql_real_

  • by WWWWolf ( 2428 ) <wwwwolf@iki.fi> on Monday May 12, 2008 @04:08AM (#23375388) Homepage

    So does this mean that if you are using magic quotes and you upgrade to PHP6, suddenly you will become vulnerable to SQL injection attack?

    "The Management would like to announce that we're switching to slot-loading CD-ROM drives next week. We will be reserving more burn ointments in the first aid room for the next week or so and the janitor has been instructed to stock extra tissues in the bathrooms, but people who have been using CD-ROM drives as coffee cup holders should seriously stop using them as coffee cup holders ASAP."

    Magic quotes did the wrong fix that incidentally happened to work for some people. The problem was that people had been concatenating (unprocessed) parameters to SQL queries; the right solution would have been to process the quoting in the place where it's supposed to be processed (query parametrisation, right before the query actually goes to the DB, automagically using the method that works appropriately for the DBMS in question), but instead, the developers just said "well, we're letting you continue your dangerous way of coding, here's a band-aid fix".

    I've viewed magic quotes as a feature for legacy code that seriously needs to be fixed: "people used to code completely freaking headlessly back in the day because we didn't have real security back then and this was the ONLY way to do things - this feature is a temporary security feature so that they have time to port their utterly reeking PHP3-era string concatenation crap to use DB-specific quote calls or, far better yet, PDO and prepared statements." Using prepared statements makes the code look more manageable and more in line with the stuff you see in other programming languages, which have used prepared statements for a long time now - porting old code over is more than entirely justifiable.

  • by Dogtanian ( 588974 ) on Monday May 12, 2008 @08:32AM (#23376556) Homepage

    it's not like writing your own string library is any monumental task.
    Your string library still looks somewhat clumsy, particularly for small projects. And I note that your functions only concatenate two strings; what if you want to stick a few together at once? (Yes, you could use var-args, but what's the checking like on that)

    What if you want to append a number to a string? Given that standard C doesn't support overloading, would you have to write a new *differently-named* method? It'd be a nuisance to have to keep track of all the different methods when (e.g.) PHP can simply do the whole lot using the '+' operator.

    it's a scripting language, it makes no sense to resemble C in any respect.
    Wrong; it makes perfect sense to use C-style syntax. That's almost certainly the most common syntax by far, used as it is in C++, Java, JavaScript, C# and many other languages.

    Visual Basic's syntax is different, and I had to learn this all over again when I used it for the first time, because I'm used to C-influenced languages. The mental context switch required and my tendency to keep inadvertantly using C-style syntax (leading to syntax errors) is a PITA.

    I wouldn't mind if the VB syntax was nice to begin with, but it's not. It's inelegant and clunky; probably not bad considering it was derived from BASIC, but still inelegant and clunky. It probably got that way because it mutated from BASICs MS-DOS/PC programmers were familiar with, carrying them along with it. However, if (like me) you're not already used to that flavour of BASIC and haven't even used BASIC for years, it's not easy to use at all. It's not even that much like the old BASICs I used to use. Though this is getting away from the main point...

    There may be valid reasons for using a different syntax, but those should reflect underlying differences in the structure/approach of the language (even Perl syntax is somewhat C-flavoured in various respects). However, using a fundamentally different syntax just for the sake of it is a Bad Idea. PHP is easier to use because it has a C-derived syntax.
  • by Tetsujin ( 103070 ) on Monday May 12, 2008 @11:55AM (#23379088) Homepage Journal
    This attitude - that new versions of the language should always support everything the old versions supported - only makes sense if you assume that the initial design was perfectly sound to begin with.

    Had PHP4 been perfectly designed, and perfectly well-suited to what people are now using PHP for, there wouldn't be any need to change it at all. But PHP isn't perfect. They've found ways to make it better. They could fork off a new project containing those changes - but PHP6 is more like PHP5 than not - and if they had to fork off every time they changed things around they'd have a lot of extraneous extra names for basically the same thing.

    Also consider - how much time and effort might they have to put in to augmenting PHP6 to be fully backward-compatible, and to maintain that awkwardness - even in the face of new features that may flat-out contradict older policies in the language? How much work would have to be wasted just to make PHP6 a better PHP4 than PHP4 is?

    If you wrote your code for PHP4, just keep running it on PHP4 until you're ready to port it.

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (5) All right, who's the wiseguy who stuck this trigraph stuff in here?

Working...