PHP6 Wishlist

Wildhoney · 11-05-2007, 11:47 PM

With PHP6 well under way and a few snapshots available. We know quite a few of the features they are implementing. However, what would you like to see?

To start it off, I'd like to see namespaces in PHP6. There is some talk of adding namespaces, but I doubt it'll happen in all honesty. I suppose we could use static functions inside classes, to have like:

PHP Code:


			
String::getAbstract($myString);

But I'd rather they introduced proper namespaces. I'm not sure what symbol they could use. Perhaps:

PHP Code:


			
String:getAbstract($myString);

Salathe · 11-06-2007, 12:31 AM

Personally I'd quite like to see namespaces implemented as below. But however they're done I don't mind too much so long as they are introduced!

PHP Code:


			
namespace Salathe
{
    private static final class InternalClass  // how cool would this be?!!
    {
        // some some internal-type things
    }
}

I'd maybe also like wider adoption of OOP in the core, so stepping away from the hoards of differently patterned function names. This has happened to some extent already, but more, more, more please. :)

Wildhoney · 11-06-2007, 01:09 AM

It would be nice, but I just don't see it happening, do you? PHP's functions are getting ridiculous these days. The one I always pull people on is strip_tags to stripslashes, and after reading the founder's comments about the inconsistency, total cop out. Come on lads, sort it out!

Nor · 11-06-2007, 01:20 AM

Would be cool if there was a new hash algorithms. Something fresh thats more secure then md5 and sha1 :D.

Andrew · 11-16-2007, 01:25 AM

Quote:

Originally Posted by Nor

Would be cool if there was a new hash algorithms. Something fresh thats more secure then md5 and sha1 :D.

Add a dynamic salt to a md5 or sha1, and it's just as, if not, more secure than a new algorithm.

Nor · 11-16-2007, 04:24 AM

Quote:

Originally Posted by Andrew

Add a dynamic salt to a md5 or sha1, and it's just as, if not, more secure than a new algorithm.

lol how can you predict the future if its not here yet?

Function overloading, multiple inheritance.

Andrew · 11-16-2007, 06:10 AM

Quote:

Originally Posted by Nor

lol how can you predict the future if its not here yet?

Function overloading, multiple inheritance.

That's not predicting the future really. With dynamic salts, it's impossible for someone to decrypt an encrypted password by using a reverse-anything algorithm. No matter how good an encryption algorithm can be, it can't be better than uncrackable.

sunilbhatia79 · 11-16-2007, 08:01 AM

Having type strict variables will solve most of the problems that we currently face with PHP... also PHP should not allow unlimited number of arguments in functions... this will solve the problem that functions cannot be overloaded

Webitz · 11-15-2007, 03:03 PM

I don't really see a point in a new hash algorithm, md5/sha1 work just fine - throw in an SSL on the line and you're quids in.

I would although like to see the whitespace error resolved when you include Javascript in a page with the header() function.

Karl · 11-15-2007, 03:05 PM

Some multiple inheritance maybe? Also operator overloading would be a really nice addition.

dschreck · 11-16-2007, 01:46 AM

Quote:

Originally Posted by Karl

Some multiple inheritance maybe? Also operator overloading would be a really nice addition.

I fully agree, but then again, i think a change like this could wreak havoc on some people's scripts... but I'd like to at least have the option to use it.

Other than that, I'd like to see things like xdebug be built in as a true debug profiler, and have them fix the damn Filter functions. they are le poo.

DarkPrince11 · 11-16-2007, 03:33 AM

Quote:

Originally Posted by dschreck

I fully agree, but then again, i think a change like this could wreak havoc on some people's scripts... but I'd like to at least have the option to use it.

Other than that, I'd like to see things like xdebug be built in as a true debug profiler, and have them fix the damn Filter functions. they are le poo.

I agree with dschreck on the xdebug. That would greatly help in debugging scripts not to mention the time it could save. Operator Overloading would be nice but it doesn't seem that important to me. Namespaces would be a great addition to the language. They had it in the PHP5 betas but took it out because it was buggy.

Wildhoney · 11-16-2007, 12:33 PM

I would actually like strict data types as well. I hear that they've actually begun to add namespaces into PHP6, but we shall wait and see because you know what happened in PHP5 - they added namespaces and then removed them altogether just before its release.

Morishani · 11-16-2007, 02:11 PM

Quote:

Originally Posted by Wildhoney

I would actually like strict data types as well.

Amen :)

Strict data types, type hinting and all the things that comes around that.

BTW
People around the web talking about the next formula :

Quote:

PHP 5.3 = PHP6 - Unicode

Because PHP6 is comming in late 2008, The PHP development team will bring us PHP5.3 That will have everything that will be in PHP6 except Unicode and some other minor things.

dschreck · 11-16-2007, 05:25 PM

I've also heard that all PHP6 is going to be is just really Unicode. Forget where I read that... think it was on a blog or something. See if I can't dig up the article.

I have to disagree with making PHP a strictly typed language. Yes, it's very very weakly typed... but that's one of the things that makes it so easy for newbies to comprehend. You can still use type casting... you can still enforce the number of arguments passed to a variable through interfaces.
And again, one of the more attractive features of PHP is that it has so many premade functions for you, that make it quick and easy to learn and do something with PHP.

So I don't think they should take away from PHP, especially in a way that could drastically deform the language.

SO, yeah, adding features like namespaces, that would be cool, but I don't feel it should have to be enforced. It's a scripting language. It should stay scripty.

wGEric · 11-16-2007, 05:56 PM

Quote:

Originally Posted by dschreck

I've also heard that all PHP6 is going to be is just really Unicode. Forget where I read that... think it was on a blog or something. See if I can't dig up the article.

That would be nice so that it has full UTF-8 support.

C01t · 11-29-2007, 11:34 AM

Namespaces should be!!! And it's already more that just a script language!!!

But I can't figure out why not to add operator overloading.
I think that if we have array access through iterators in SPL, so they can introduce something like MathInterface witch will allow overloading of operators.

Simply like:

PHP Code:


			
class foo implements AddOperator

{

    public function operatorAdd(foo &$object) 

    {

        /* @todo adding does here */

    }

}

If array access is posible then that is possible too

Webitz · 11-16-2007, 12:39 PM

I hate the idea of strict datatypes - it's why I stay away from languages like ASP. Also I don't see much advantage in namespaces to be honest, I don't think much should change on the variables side of things. It would also be nice to see some new useful URL rewriting functions available without Apache - Only because im on IIS and rewriting is a pain in the ash.

Wildhoney · 11-16-2007, 01:30 PM

Namespaces will be a life saver when you realise that so many global functions is a really bad idea. URL rewriting will always remain with Apache as that's not a PHP task at all - even Ruby on Rails uses Apache's mod-rewrite, so I think you're well out of luck on that one. Namespaces are useful as it gets rid of those prefixed functions you see dotted around the place - simplexml_* to name one. You would just do something like:

php Code:

use SimpleXML as SXML;

$pXML = new SXML::SimpleXML;
echo $pXML->load_file();

Webitz · 11-16-2007, 02:00 PM

Ah yes, in regards to URL rewriting, imagine a function took the whole URL and split it up, if it find for example "users_id" in whatever.com/showuser/users_id/100.php then it would use from the slash after users_id to the end, if it sees .php remove it, if it sees / (due to more parameteres) then carry on collecting data. This could be made using your own load of functions but I suspect its a dodgy one to write... I think I may look into doing it myself.