The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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.

... 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.

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?

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...

Isn't that currrently how PHP works anyway? Integers on 64bit systems are 64bits. They're only adding a new int64 which will be 64bits regardless of the system.

I don't know, from the discussions it looks pretty good. They're cleaning up the language, which is a good thing. Yes, of course that causes compatability issues, it always will. But that's part of upgrading, isn't it? It's not like they're suddenly dropping features, they're removing depreceated, archaic, and unused stuff.

XMLReader and XMLWriter in the default distribution seems handy as well. All in all this seems like a pretty positive step for PHP. It needs a cleanup, sometimes things just get clunky. Goto support is not decided on yet, so we can't really complain yet.

My main concern, of course, is this focus to PHP 6. Most of my clients have hosting with PHP 4. With PHP 5 penetration not that deep yet, they're already jumping to another major version?

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.

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.