This is where we starting complainin' about PHP6

vaaaska

😉

Sure, why not...I know it's been making the rounds but this one might serve as a place to start fussing over things (there's plenty of links going on here). Especially OOP'ness.

http://jero.net/blog/2006/03/php6/

And the very first comment reads (here comes the controversy):

I read about the new php and was surprised; but the thing is, the more PHP becomes like a real OOP language, the less people will code with it. Maybe that’s why php4 has been around for so long.

I'd sure like to see much, much, much better support to internaliational languages.

Weedpacket

Decent Unicode support (but not at the expense of turning every string into two bytes per character, mkay?)

Namespaces. Yes, please. I mean, have a look at the Zend Framework:

//[file Zend/XmlRpc/Value/Exception.php]

require_once 'Zend/XmlRpc/Exception.php';

class Zend_XmlRpc_Value_Exception extends Zend_XmlRpc_Exception
{}

laserlight

Arghh! They want to intoduce goto!

Okay, maybe not. The reduced goto/empowered break functionality is one of the better uses of goto in other languages, but I wonder what are the ways to abuse it....

dream_scape

Weedpacket wrote:
Decent Unicode support (but not at the expense of turning every string into two bytes per character, mkay?)

Yes I am looking forward to nice unicode support as well. If I'm not mistaken, unicode (UTF-8) breaks down as follows for bytes/character:

Chars 0 - 127 = 1 byte/character
Chars 128 - 2047 = 2 bytes/character
Chars 2048 - 65535 = 3 bytes/character
Chars 65536 - ?? = 4 bytes/character

PS. those are unicode character codes. I believe unicode 0 - 127 is the same as ASCII 0 - 127, but from there they are different I think (but they might be the same up to 255, but I'm not sure if the extended ASCII character codes are the same code in unicode for the same character).

Jason_Batten

PHP3, PHP4, PHP6... Wait a minute? What are we missing here?

I don't see why they can't make a few of the changes they want to in PHP6 to PHP5. It seems they just want to fart out another version number. PHP6 apparently seems to mean "enterprise".

dream_scape

we already have 5 and 5.1... duhhhhh...

plus there is no rule book on version numbering... they can number it however the freakin' hell they see fit.

with some of the major changes like Unicode support & namespaces to name a few, plus planned removal of a ton of depreciated and legacy code & functionality, I think a version change is not unwarranted.

Jason_Batten

They should have been done in PHP5.

bpat1434

I think they're calling it PHP6 because it's a major rewrite of core code, and a general update (like PHP 5 was). So I think it can be expected that certain things in PHP 6 will show up as deprecated since they were written for PHP 5. Honestly, I don't see why the number is a sore point. The number means nothing... it's the content of the product that really matters.

I like PHP 5, but I can't wait to see what PHP6 can do as far as OOP and better language support. Plus, it seems to be moving in a direction so that more regular coders can actually code for PHP. Since we're seeing the inception of PHPGTK, I think they're trying to slowly migrate towards the desktop coding evironment. Possibly give C a run for its money... Who knows... maybe we'll see PHP as an OS soon . . . lol.

Eh... PHP 6 will be a good upgrade, but it will probably take on just as slow if not slower than PHP 5... but I don't expect it to be out any time soon... I'd be guessing 2008 at the earliest... gives them over a year and a half to get it ready...

plus there is no rule book on version numbering.

That's not entirely true. There are guidelines. Like the *nix versioning system says that major core updates are your major version, after the first dot is the minor version, second dot is the patch, and if there's a third dot it's usually the build.

Apache and Linux follow the 3 number rule:
Major.minor.Patch
Linux 2.2.4
Apache 2.1.5
PHP 5.1.2

There are "guidelines" but they don't need to be followed . . .
Note the Wikipedia!!

Jason_Batten

I think they're calling it PHP6 because it's a major rewrite of core code, and a general update (like PHP 5 was).

You're calling the PHP5 OOP functionality a general update? You're calling the MySQL Improved Extension a general update?

bpat1434

no, I was saying PHP5 was a core update as well as general updates. So there were bug-fixes, stability fixes, security patches, as well as core-rewrites. It was a major update, hence why it's not fully backward compatible.

That's what I meant....

Jason_Batten

and you think PHP6 will be a major update? It doesn't seem to be that big yet.

Weedpacket

laserlight wrote:
I wonder what are the ways to abuse it....

The restrictions appear to avoid the worst spaghetti code; you can emulate the described behaviour now by writing

for ($i = 0; $i < 9; $i++)
{
        if (true) {
                break blah;
        }
        echo "not shown";
blah:
        echo "iteration $i\n";
}

for ($i = 0; $i < 9; $i++)
{
        do
        {
                if (true) {
                        break;
                }
                echo "not shown";
        } while (false);
        echo "iteration $i\n";
}

But I wouldn't be at all surprised if there are new and wonderful ways of writing horrible code as a result.

if($got_a_big_stick)
    break bones;
else
    break balls;

Weedpacket

dream.scape wrote:
Yes I am looking forward to nice unicode support as well. If I'm not mistaken, unicode (UTF-8) breaks down as follows for bytes/character:

UTF8 is an encoding for Unicode that was designed to be 1:1 compatible with ASCII; Java for example stores the full UCS16 encoding.

And no, I would not like to see UTF8-based strings as the compromise: that would bring no end of grief when trying to interpret a string as a byte stream or vice versa. A UString type would be nicer - whether stored as UCS16 or UTF8 internally I don't know, but probably mapped to UTF8 when being cast to an ordinary string.

bpat1434

and you think PHP6 will be a major update? It doesn't seem to be that big yet.

Well, yeah it does. I'm not gonna argue what makes a major release, but what they're talking about updating, they keep alluding to the fact that they have to rewrite some part of the core, remove stuff, add stuff, streamline code... from what they're talking about it seems like a lot. And that's just the beginning. From right now it seems like a major update. But really, they could call it PHP 8 if they really wanted to. There is nothing that says they have to go cronologically.

Merve

I read about the new php and was surprised; but the thing is, the more PHP becomes like a real OOP language, the less people will code with it. Maybe that’s why php4 has been around for so long.

That comment is total garbage. I've been messing around with PHP for about 2 years and I've had to use OOP only ONCE, when I was working with a class to create and manipulate zip archives. It's not like they're forcing you to use OOP; anything you code can be strictly procedural. The OOP components are there to use if you so choose. In fact, it's a good thing that they were implemented because they'll actually attract more programmers familiar with languages such as Java.

And the reason that PHP4 has been around for so long is that the PHP development team continues to support and update it; PHP 4.4.2 was released on January 13th!

Elizabeth

If anyone wants to eavesdrop on the internals' core development conversations about what's going on with the development of PHP6 (and thus end speculation about why they are doing what they're doing, and how they will go about doing it) then all you need to do is sign up for the internals mailing list:
http://www.php.net/mailing-lists.php

It's pretty eye-opening.