Springtime for PHP6 in Paris

[arborint]

Very interesting (and long) notes by Derick Rethans covering the PHP developers discussion of PHP6 in Paris. Interesting reading.

http://www.php.net/~derick/meeting-notes.html

[{RainmakeR}]

OMG I nearly died when I saw item 4.2!!

[beetle]

OMG I nearly died when I saw item 4.2!!

They way they are going to implement it isn't totally crazy. You can already do that with javascript, for example.

[wei]

Are there any "good" reason to use item 4.2 at all? Are there any wild estimated ETA for php6?

[lazy_yogi]

I'd like to see some code that is better implemented with GOTO.
Someone make me a believer.

[shiflett]

The goto debate is tired, and I doubt anyone can come up with new arguments.

The reason for having any language feature is to put more power in the hands of developers. This is what I've always loved about PHP. It gives you plenty of rope with which to hang yourself. :-)

[arborint]

I'd like to see some code that is better implemented with GOTO.
Someone make me a believer.

There are a number of examples of programming problems that are not well expressed using only structured programming constructs. Parsers are one of the most common examples, but there are others if you search the literature. Generally they are problems that have multiple conditions for block entrance and exit.

It is fairly common knowledge that structured programming, or OOP for that matter, while generally very good at most things are are not good at expressing some programming problems (you can't expect perfection). And even structured programming added the switch statement which -- though not that often used -- is just a disguised goto. The warnings against using goto are for beginning programmers (who should only have if and while anyway). Experienced programmers will judiciously use language constructs as appropriate.

[arborint]

I was interested in a comment by one of those present, Andrei Zmievski:

... once 5.1 is out, I think we can concentrate on the implementation of PHP 6, which should be great.

It sounds like the 5 series may not have quite as long a run as the 4 series -- if the focus after 5.1 is on a 6.0 release.

[beetle]

I'd like to see some code that is better implemented with GOTO.
Someone make me a believer.

The one person I'm sure of who doesn't know everything is the very man to claim just that.

It's true that a "goto"-like construct may rarely if-ever be useful in the problems most web-application developers face, but I don't pretend to know so much as to say it would never help.

[stereofrog]

Thanks, arborint, really interesting reading!

There will be two string types: Binary (which is non-unicode) and String (which can be unicode or not, depending on ini setting). Similarly, there will be two integers: Int64 (which is always 64 bit) and Int (which is 32- or 64-bit depending on the current machine's word size). I've a strange feeling this can cause some portability troubles...

Can anybody explain 5.10? What's so " dangerous" about calling the same function as static and dynamic?

[kyberfabrikken]

I've a strange feeling this can cause some portability troubles...

Yes, that sounds like a recipie for disaster. At least we now have the preservation to come out in two years and say "I told you so".

[n0other]

Thanks for the link aborint.

Do we really need type-hinting for function return values?

[Ezku]

I was, really, really disappointed seeing that. I was looking forward to them making the OO model better, but all we seem to be going to get is namespace support. Sorta.

[dbevfat]

... And even structured programming added the switch statement which -- though not that often used -- is just a disguised goto. ...

I believe switch is a disguised if statement, not goto.

I've never seen a single piece of code that would actually benefit from goto, in terms of code clarity, flow and ease of maintenance. Can any of you that disagree with that post an example of such code? I'm always open to different approaches.

Best regards

[stereofrog]

How would you write the following:

if cond1 do action1
elsif cond2 do action2, then do action1
elsif cond3 do action3, then do action1

where conditions are dependant (cannot be reordered)?

See also often quoted discussion at http://kerneltrap.org/node/553

[mx2k]

I was, really, really disappointed seeing that. I was looking forward to them making the OO model better, but all we seem to be going to get is namespace support. Sorta.

even that looks disappointing.....

$x = new company\web\class(); or

import company\web;

and not one mention of a property keyword ....sigh =(

i think i need to get rich, then go learn some c/c++ and extend my own version of php. sigh.

[lastcraft]

Hi.

Actually I am glad to see the feature set is pretty small. They are taking stuff out at last, moving things to PECL and they rejected a whole bunch of stuff . After all the crap they put in last time (final?, type hints) it would be good to get cleaner. That will speed development in itself.

Adding dodgy language constructs (like GOTO) will slow development of PHP7. There is a big cost to adding a feature. You can never say GOTO is OK just because you cannot see a reason against it, there is always a hefty cost. It's just dumb management.

I am not sure what use type hinting on return values will be either. Handy for the Zend IDE, but not much else. PHP could have managed quite happily without type hints in the first place IMO. I'd rather have seen a smooth migration from 4 to 5 higher on the priorities.

There is one worrying thing about this. The idea that 5.1 is deemphisized in favour of 6. They should make sure they employ the talent on the current version, not just the fun new one. PHP5 has a huge number of very damaging bugs right at the OO core. I noticed that they have removed the OO category from the bug statistics page now and "phpsniper" has got his dream of marking them all bogus, but they are still there. I'd like to see those fixed.

Unicode is good move though. That will remove a whole load of junk from the language. Shame they couldn't have dome that gradually.

Regarding namespaces, the number one problem I have is importing legacy bits from all over the web and avoiding nameclashes. Any import faclity has to be able to import unnamed legacy code under a namespace.

yours, Marcus

p.s. My favourite useless syntatictic sugar would be defining methods like this...

class WithStuff {
    public $_stuff;
    public $_more_stuff;
    
    function WithStuff($this->_stuff, $this->_more_stuff) { }
} 

Would cut out lot's of useless chains of assignment.

[BerislavLopac]

I haven't even read the link yet, and you guys made me afraid already. Seems I'll really have to dive into Python then...

[BerislavLopac]

Just found this in Derick's notes:

As PHP is a weekly typed language this kind of functionality does not make sense in PHP.

First, the typo is hilarious.

However, it makes me sad when I see that the base contributors do not know the difference between weakly and dynamically typed languages.

[kabatak]

As PHP is a weekly typed language this kind of functionality does not make sense in PHP.

HAH. Now that makes sense why php didn't care about types.

[mx2k]

import unnamed legacy code under a namespace.

wouldn't that possibly just go under the global namespace by default?


and just in general, how bad would it be to be able initalize an object through a private field when defining fields inside the class?

[xmitchx]

I very much enjoy many of the features that are being implemented into PHP6... but I also notice that many of them are core features of Ruby already

[BerislavLopac]

I very much enjoy many of the features that are being implemented into PHP6... but I also notice that many of them are core features of Ruby already

Don't compare apples and oranges. Ruby is a general-purpose language designed ground-up as an OO language. PHP is a scripting language running on top of a Web platform that was originally designed as purely procedural.

[DougBTX]

Off Topic:

Don't compare apples and oranges.

Why not?

Oranges are more juicy than apples, though the skin on apples tastes better.

See, we can compare them. Just as we can compare PHP and Ruby. No need to be offended by this.

You can't claim that two things are incomparable just because ther are different, otherwise there would be little need for comparison in the first place.

[stereofrog]

Well, if php would be what it should be, namely object pascal with c syntax, I'd probably choose it over ruby.