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.

What I want for PHP 6 Christmas...

When PHP 6 comes out I really only want one thing. Admittedly it's a major thing, but I believe it would help the language out a hell of a lot. That one thing - place all existing functions in a legacy namespace and then rebuild the function library with consistently named functions in an object oriented fashion.

The existing functions would still be around - they just would have to be imported and for backwards compatibility a flag would be placed in the php.ini file that would do this automatically. It could even ship with the value set to true.

But if it's set to false the scatterbrained php function library goes away replaced with one planned out from the start and itself divided into namespaces.

So this weird situation of string functions sometimes having underscores and sometimes not -- strpos, strchr, str_replace, str_split; or not even referencing strings in the name; explode and implode; goes away. Instead.

PHP Code:

$a = "The quickbrown fox jumped over the lazy dog";

$a->position('dog'); // Find the position of dog in $a$b = $a->explode(' '); // Explode $a into an array and return it to $b.$a->explode(' '); // As above, but since there is no var to assign it to $a will become an array and hold the result of the explode.

$a->shuffle(); // Shuffle the order of the elements..

And so on. Functions could also be rewritten to throw exceptions for exceptional circumstances, not merely return false as many do right now.

The way it may happened in php is if someone writes an extension or even better if object that represents a string is added to SPL
Then we could just extend that class to add any new methods we may want a string to have, for example some sort of charset converter built in the string object would be nice.

Well, we'll see. Then again, there is a project out there to effectively do server-side Javascript. If that was done correctly, I'd switch.

Even if functions aren't mapped to objects as above there are still compelling reasons to remap the function library into namespace collections, including I would imagine performance reasons. For example if I'm working in mysql I don't need the mssql or postogre functions, or any of the other db libraries. I could just import the database library I need into my namespace and use it.

I though of another feature today, I think the session should be an object and not an array in php. Maybe an object of type ArrayObject from SPL, so it can still work with most existing php codes, but giving the user the ability to extend the session class would be great.

The whole point of backwards compatibility is to support legacy applications. Making legacy applications have to change to use a namespace makes the whole idea completely pointless.

And that would be why it would ship with the php.ini directive import_legacy_namespace set to true?? Duh. Legacy aps would only break if you change that setting. Besides, a lot of legacy aps are already going to break with register_globals and magic_quotes goes buh-bye.

There is simply no point in doing this at all. What advantages would it serve? Whilst we're at it why not convert all datatypes to objects? The great thing about PHP is that it's data types are so flexible. I don't have to piss around converting between data types like in more strict languages such as Java

There is simply no point in doing this at all. What advantages would it serve? Whilst we're at it why not convert all datatypes to objects? The great thing about PHP is that it's data types are so flexible. I don't have to piss around converting between data types like in more strict languages such as Java

One advantage of strict datatype is to catch error early by using type hinting.
If you make a mistake and pass a string where integer is expected, you get an error right away. This usually helps with debugging. Of cause this is more important in compiled languages like Java where compiler will catch all the wrong datatypes and will refuse to compile untill you fix the errors.

In php there is no compiling stage so nothing will catch your error until something goes wrong with your script somewhere down the line.

I think making datatypes objects is not a bad idea. I think Java got that right, php did not, it will get there eventually.

One advantage of strict datatype is to catch error early by using type hinting.
If you make a mistake and pass a string where integer is expected, you get an error right away. This usually helps with debugging. Of cause this is more important in compiled languages like Java where compiler will catch all the wrong datatypes and will refuse to compile untill you fix the errors.

In php there is no compiling stage so nothing will catch your error until something goes wrong with your script somewhere down the line.

I think making datatypes objects is not a bad idea. I think Java got that right, php did not, it will get there eventually.

thank you for this sir, may I ask do you learn this on you own? I remember my professor told us this once.

There have been a few incidents through the course of debugging where loose datatypes have been the source of problems, which never would've occurred under a strict datatype environment

(yes, I used Java before eventually turning to PHP. While PHP is easier in the long run, the two things I do dislike about it are the lack of strict datatypes and the inconsistencies in function naming and behavior)

The answer here, IMHO, is not bemoaning the lack of strict data types, but rather developing within ourselves the discipline to more strictly code our pages. If you want to avoid issues with mis-cast data types, then code in such a way that this is not an issue. And to those who say "Use a different language", that doesn't help, other than to inflame emotions. PHP is a great scripting language, and is powerful and flexible. However, it's so forgiving in some ways that it almost encourages us to become lazy. I say that WE are the keys to eliminating these potential problems, in the way that we code.