Follow Slashdot stories on Twitter

 



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 unity100 ( 970058 ) on Sunday May 11, 2008 @06:03PM (#23372008) Homepage Journal
    i am servicing around 350+ clients in a small fish web host. even at that small web host, there are a phletora of different scripts, programs that clients are using to conduct their everyday business, their estores, their livelihood. some of them are dependent and locked-in to the software they are using like a small business company that extensively uses ms products is locked into microsoft.

    regardless, backwards compatibility is important for those people. for starters, these are the people who have chosen php as the platform to conduct their business on, making php a de facto dominant language for the web instead of being a small time web language that was used on web savvy, webmasters. the financial impact of this is going to be huge for them, to adopt to that many changes php dev group started to introduce in the span of 1 to 2 years. this is too much.

    you gotta slow down. or you are going to alienate the small business community from using php with what you are doing. if you break a small estore owner's store script every 1.5 years for 'upgrading', the second time you do it they will jump the language ship.

    do not start to become an elitist group out of touch with the people, increasingly caring for nifty programming issues rather than what would the users think.
  • by Anonymous Coward on Sunday May 11, 2008 @06:15PM (#23372096)
    And forward innovation is not important? Besides, you wouldn't upgrade all 350+ clients at once and in place? Perhaps having two host accounts, one for php5 apps and one for php6? Just a thought.
  • by njcoder ( 657816 ) on Sunday May 11, 2008 @06:51PM (#23372384)
    Sounds like you're using mod_php. That's a very insecure way to run php in a shared hosting environment and also doesn't give you the ability to run more than one version of php.

    May not seem like a big deal until some idiot doesn't update his scripts and some script kiddie comes along and you get 350 calls from your clients asking you why there's some terrorist propaganda on their website.
  • by sneakyimp ( 1161443 ) on Sunday May 11, 2008 @06:59PM (#23372422)
    I've noticed that every single article here mentioning PHP is immediately tagged 'phpsucks'. I find PHP incredibly expressive and am always surprised by the incredible variety of libraries/modules/plugins to manipulate graphics, flash, pdfs, to support protocols like SOAP, JSON, etc.

    Perhaps we need an article on 'why php sucks' ?
  • by FooAtWFU ( 699187 ) on Sunday May 11, 2008 @07:10PM (#23372506) Homepage
    You mean like this? [www.tnx.nl]

    It's not the lack of modules that people complain about. PHP is excessively convenient, if nothing else. :)

  • by FilthCatcher ( 531259 ) on Sunday May 11, 2008 @07:15PM (#23372534) Homepage
    My biggest issue with new PHP changes is fact that the sheer size of the PHP libraries mean that these new features don't bubble through to the whole core.

    For exmaple take the newish try / catch exception features. On first glance you think "finally I can write decent exception handling into my own code" - which is great for your own exceptions but too many of the core functions used by your code or by a framework you're using don't throw exceptions - they indicate an error codition in the function's result.

    So now we're seeing loads of code out there by people trying to do things "The right way (tm)" but it's full of bugs as there's exception conditions being raised by core functions that don't get caught by the catch blocks.

    The line from TFA that concerns me is "Much improved for PHP V6 is support for Unicode strings in many of the core functions"

    Many? That will means developers will start using unicode only to find scattered lines of code throughout the app doesn't work as the core function it uses doesn't support unicode. The overhead of keeping track of which functions do and don't support unicode will be a nightmare.
  • by Anonymous Coward on Sunday May 11, 2008 @08:58PM (#23373122)

    I have programmed in assembler, Basic, C, C++, VB, VBScript, WordBasic, Java, Javascript (and Jscript), Actionscript (1, 2, and 3), Lisp, and Pascal. I disagree that any of these are more expressive than PHP.

    Then please describe what you mean when you say "expressive", because you and I seem to have wildly differing definitions.

    Also, to assume it's all I know is *really* irritating.

    The only likely explanation I could think of for you considering PHP to be expressive is that you had not been exposed to any other language. My next hypothesis is that you didn't actually mean expressive. If that also proves to be false, I will look for another explanation, because the idea that somebody might actually consider PHP to be more expressive than other languages is extremely unlikely. I rank you blatantly lying as more likely than you genuinely considering PHP to be expressive while having knowledge of other languages.

    This is not mindless PHP bashing. I have used PHP for years myself. It has its good points and its bad points. But it is simply not expressive compared with other languages. Even most die-hard PHP advocates recognise that. Hell, ask the guys at Zend, and even they will probably tell you that PHP's strengths lie elsewhere.

  • by SanityInAnarchy ( 655584 ) <ninja@slaphack.com> on Sunday May 11, 2008 @11:23PM (#23374084) Journal

    More pointedly: If poorly-indented code is so troublesome that you'd "hate" the offending developer, you should start using a modern IDE.
    I prefer a modern editor to a modern IDE.

    I do want a certain amount of control over the structure of my code, even if a lot of it will be by convention. Having any automated tool try to "fix" someone else's code is likely to screw up things like comments which are cleverly indented and aligned with some code, or similarly interesting code.

    And an IDE is overkill in many other ways, yet they still often find ways to miss some functionality I want. That, and I tend to be much more easily able to switch text editors than switch IDEs.

    Disclaimer: I'm not GP, and I use Ruby.
  • by encoderer ( 1060616 ) on Sunday May 11, 2008 @11:27PM (#23374116)
    Well, most users should be saved just by coincidence.

    Using the example in the article:

    <?php // Assuming magic_quotes is on...
    $sql = "INSERT INTO USERS (USERNAME) VALUES $_GET['username']";
    ?>

    If magic quotes is, indeed, on, the database will see a query that looks like this: /* Let $_GET['username'] = testUser */

    INSERT INTO USERS (USERNAME) VALUES 'testUser' ...now...

    if magic quotes is turned off, sure, an injection attack is possible, as the query will become:

    INSERT INTO USERS (USERNAME) VALUES testUser

    And as long as a dev tests their code after upgrading to v6.0 they'd notice that the DBMS has thrown a 'testUser is not a column/udf/sproc' error.

  • by encoderer ( 1060616 ) on Monday May 12, 2008 @12:25AM (#23374456)
    First, the PHP code doesn't really make sense. Why are you passing in the $args parameter?

    All this code is doing is accepting a method name, validating it as valid (yes, an Enum dt would help here), and returning it if it is.

    In which case, this is much better:

    if (is_callable($method)) {
        return method;
    }

    Or, more on point, you'd never even call the __call() method, you'd just call is_callable().

    I think the point is to show a plausible example of PHP being "hard work like C."

    I'm not a PHP apologist. It's got a lot of problems. Chief among them a glaring inconsistency that just makes an elegence-loving guy like myself cry my eyes out. But to say that it's "hard work like C" just because it retained a syntax and offers up some thin wrappers around C functions is, I believe, disingenuous.

  • by moderatorrater ( 1095745 ) on Monday May 12, 2008 @02:08AM (#23374958)

    Can you be more specific about how PHP "has a focus" on Web scripting
    PHP was made originally to program web pages and, while it's been expanded to other uses, its main focus is still web pages. $_GET, $_POST, $_SESSION, $_COOKIE, and $_REQUEST are (as far as I know) unique to PHP in being built into the core of the language. As frustrating as it sometimes is, PHP files are considered standard output unless they have tags enclosing them, whereas in perl everything is considered code unless stated otherwise.

    Loose typing and non-strict syntax in general is particularly well suited to the internet because each request generates a completely new environment. Something that was wrong with the previous request, unless specifically stored, doesn't affect the next request. Strictness in programming stems from the need to keep far flung parts from affecting each other; the web is modular by nature and thus resistant to wide spread bugs. Thus, loose typing and other, less strict forms of programming that make life easier at the expense of fragility is counterbalanced by the modular nature.

    Many won't agree with that analysis, and that's fine. Sloppy coding has gotten more than one web project in trouble, and more than one feature of PHP's that was intended to make life easier ended up going to far and introducing security holes. But that doesn't change the simple fact that PHP was made for the web and has conveniences built into the core that other languages either don't have or require an add on for.
  • by Wiseman1024 ( 993899 ) on Monday May 12, 2008 @04:06AM (#23375378)
    Better Unicode support, which is a major, desirable feature, as others pointed out, and as far as I know, magic_quotes won't be deprecated in 5.3. Just deprecating magic_quotes, the last piece of shit to get rid of (the other two were register_globals and safe_mode) justifies a new major version giving PHP a refreshed image. They finally got rid of three of the worst features ever thought in a programming language other than COBOL, FORTRAN, BASIC, RPG and similar crap.

    Now they need to get rid of the fatal error on function redefinition or function not found stupidity (that was REALLY retarded, probably the single worst feature after the three I mentioned), lexical scoping, syntax for lambda-expressions, first-class functions, better garbage collection, true object-orientation, a decent class system (i.e. one that's not modelled after Java's), operator overloading, associative arrays with support for non-string keys, decent iterators which don't require you to define 235789051 methods - just one (next) as a minimum, generators, coroutines, threads, a decent eval without the return insanity, and functional programming tools. Oh, wait, they need Python!

    On top of that, I'd get rid of statements (make all of them expressions), add guaranteed tail-call elimination and get rid of the dollar sign.
  • by random0xff ( 1062770 ) on Monday May 12, 2008 @05:13AM (#23375598)

    Oh well, I guess php6 is where they are finally trying to do things right now.
    At which point it will be kind of like Java 1.2 Apart from the amazing amount of PHP code(rs) out there, it seems that PHP is destined to be old skool. With all the buzz around Ruby, Python 3, JavaScript, C# 3, how is PHP going to be a good choice for new projects in the future? Waiting for years to get namespace support while a C# coder now has generics, lambdas, a query dsl and a proper base class library. How is that cool, why be a PHP programmer? So you can have generics by 2012?
  • Re:Major version? (Score:3, Interesting)

    by Haeleth ( 414428 ) on Monday May 12, 2008 @03:11PM (#23382212) Journal
    There was actually a lot of resistance to Unicode in Japan: there were some unfortunate misunderstandings early on that led a lot of Japanese people to believe that Unicode was trying to force them to use Chinese conventions for character shapes. It also doesn't help that all the various UTFs appear to be less efficient at encoding Japanese than their various legacy encoding systems. (Of course, neither of these things is really an issue in practice, but we're talking about popular perception here!)

    I don't know if Matz was among those who held those incorrect beliefs, but even if he wasn't, there still won't have been any compelling reason for him to adopt Unicode. Multilingual character sets are only a big win if you're mixing multiple languages. If Matz didn't originally expect Ruby to take off in a big way internationally, then for the sorts of uses he probably envisaged, just Japanese and English would be fine, and you can handle that combination perfectly well using any of the legacy Japanese systems.

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

Working...