SitePoint Sponsor

User Tag List

Page 5 of 5 FirstFirst 12345
Results 101 to 113 of 113
  1. #101
    SitePoint Addict
    Join Date
    Apr 2005
    Posts
    274
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'd like to say that regardless of what features PHP 6 might have, it's release is completely irrevelent to my daily workflow
    I second this, PHP6 might have the best features ever, but it's not gonna matter even a slight bit because I can't even work with PHP5 yet! Not a single server I have to work with is running PHP5!

  2. #102
    SitePoint Addict
    Join Date
    May 2003
    Location
    Lancaster
    Posts
    240
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Having run dozens of servers i won't be "upgrading" to php5 anytime soon. Perhaps on new servers we may roll out updates and force people to upgrade.

    Problem is many of the scripts people have spent years building/customizing still don't work good or at all under php5.

    Not really an issue with webhosts but an issue with everything being designed around incompatible code that is just now being fixed.

    Many of the popular cms systems come to mind..

  3. #103
    SitePoint Member
    Join Date
    May 2005
    Posts
    19
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The changes do look pretty good, but they need to take more time on the updates..

  4. #104
    SitePoint Addict
    Join Date
    May 2005
    Posts
    255
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm still not seeing where these upgrade issues are coming from. I'd be willing to wager that the problem is coming from a systems administrator who doesn't know how to compile --with-mysql more than anything else. I'm in charge of the PHP installations on dozens of servers running tons of php4 applications (all the big ones that you're used to; PostNuke, phpBB, vBulletin, etc.), and they all work just fine. In fact, with the exception of a few extra warnings and noticed (typically the "wtf are you doing!?!!" variety, like call time pass by reference), I've yet to see any major app that breaks when running on a php5 setup.

    The benefits for using php5 far, far outweigh those little warnings and notices.

  5. #105
    SitePoint Member
    Join Date
    Aug 2005
    Posts
    2
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I do not understand why it matters if hosts have upgraded or not. If PHP4 works great for them, then let them keep it for the next 20 years. As for those people that are leading the curve, they can upgrade to the latest version and enjoy new features. Personally, I hope that 6 months after they release 5.5/6 they will release PHP 7 (fully bugged, of course) with a whole slew of new features.

  6. #106
    SitePoint Guru mwolfe's Avatar
    Join Date
    Mar 2005
    Posts
    912
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Its pretty clear why it matters to many people here, because they code for a living. If the technology is out, but nobody is supporting it, then it doesnt do them any good to try and use its advantages when it won't work on the server.

  7. #107
    SitePoint Member spyross's Avatar
    Join Date
    Oct 2003
    Location
    Rhodes, Greece
    Posts
    15
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Buddha443556
    PHP5 was released over a year ago with half way deceit backwards compatibility however not one of my host have upgraded yet. Along comes PHP6 backwards compatibility questionable to shaky with PHP4 and PHP5 ... just how far behind do they think they can leave the hosting community?

    OpCode Cache!!! I've been waiting for that. Wonder how Zend feels about that addition?

    PHP is not just about creating nice and simple database driven websites.
    PHP is - even as is - powerful enough to be used for developing powerful web based applications. Web hosts that just focus on hositng simple websites can still use PHP4 for as long as they like. I don't see why I sould have register_globals off for a website that just retrieves some trivial content data from a database has a contact form.

    On the other side, companies that rely on applications that need the extra power and features can and should use next versions of PHP.

    Nevertheless removing register_globals is a good step into making good programming practice a standard, something many php programmers lack (probably myself included).
    Welcome to the jungle!

  8. #108
    SitePoint Member auctionmonsternt's Avatar
    Join Date
    Jul 2005
    Posts
    23
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I can sum up the reason for the early release with two words (book sales)
    Auction Monster -- List for free and sell your item today!!!

  9. #109
    SitePoint Addict
    Join Date
    May 2005
    Posts
    255
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by spyross
    PHP is not just about creating nice and simple database driven websites.
    PHP is - even as is - powerful enough to be used for developing powerful web based applications. Web hosts that just focus on hositng simple websites can still use PHP4 for as long as they like. I don't see why I sould have register_globals off for a website that just retrieves some trivial content data from a database has a contact form.

    On the other side, companies that rely on applications that need the extra power and features can and should use next versions of PHP.

    Nevertheless removing register_globals is a good step into making good programming practice a standard, something many php programmers lack (probably myself included).
    PHP Code:
    <?php
    require('db.php');
    $handle mysql_connect($db_host,$db_user,$db_pass);
    mysql_select_db($db_database,$handle);
    switch(
    $do)
    {
       case 
    'update':
           
    mysql_query('UPDATE '.$table.' SET '.$field.' = '.$val.' WHERE id='.$id); 
       break;

       default:
          
    exec($cmd);
       break;
    }

    ?>
    Obviously this is kind of the extreme case, but if I were a host, I would simply never let register_globals be on any server that I run.

    [/php

  10. #110
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    PHP Code:
    <?php
    require('db.php');
    $handle mysql_connect($db_host,$db_user,$db_pass);
    mysql_select_db($db_database,$handle);
    switch(
    $_GET['do'])
    {
       case 
    'update':
           
    mysql_query('UPDATE '.$_GET['table'].' SET '.$_GET['field'].' = '.$_GET['val'].' WHERE id='.$_GET['id']); 
       break;

       default:
          
    exec($_GET['cmd']);
       break;
    }

    ?>
    I suppose that's where magic quotes comes in...
    Hello World

  11. #111
    Web developer Carl's Avatar
    Join Date
    Sep 2003
    Location
    sweden
    Posts
    320
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think many are confusing the backwards compatibility issue with proper project control. php5 and php6 would be the same branch. php6 would exist because of the version number conventions used nowadays to seperate major changes in software operation by going to a full version number rather than a point. The changes listed are very major. So php5 would only exist up to 5.04 and then become php6. Web hosts will consider this reasonable and hang along for the ride.

    As far as the complaints of just now getting to php5 and now having to do php6. They don't hold water. Unlike Microsofts changes in .NET technology the changes stated are not items that need to be learned or will effect present use. If you are learning or using php5 then most of the items are things that you should not be using or will not have to learn about. So backwards compatibility becomes a non factor.

  12. #112
    SitePoint Enthusiast
    Join Date
    Dec 2004
    Posts
    43
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    What is the general opinion about Unicode support among the PHP developers? What does Unicode support mean?

    What will strings be stored as internally? I suspect UCS-4. There's several Unicode encodings: UCS-2 and UCS-4 along with the transformation formats UTF-8 and UTF-16. There's also little endian and big endian, and the byte-order-mark to be concerned with.

    Will there be special print, echo, and company functions for each encoding? Will print, echo, and company have parameters for the encoding to be used? Perhaps the encoding can be set with a seperate function, much like for how the locale is set.

    I suspect the developers will use IBM's ICU. I've been using it with my own applications in C. It's quite nice and easy to learn.

  13. #113
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Joseph, read the PHP internals mailing list archives to get a picture of what the plans are. Internally, I believe most things will be in UTF-16, with no special print, echo, etc functions. The last I saw, there was still some disagreement on whether support for turning unicode support off would be possible, the results of that will probably affect the final setup.

    Douglas
    Hello World


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •