I have some experience with Assembler, ANSI C, C++, C# and MATLAB (not as much as Dan, of course). I agree that PHP is a little ugly compared to let’s say C# but I still like it because it can get the job done fast and is imho ideal for web. Of course, for desktop, it would be horrible but nobody is suggesting to use PHP for desktop applications.
To be honest, I wish more languages used the $ dollar sign syntax for variables. Adding an identifying character the beginning of variables makes code significantly clearer at a glance, and allows for certain features just not possible without it, such as parsing variables within strings and dynamic variable accessors; plus it can solve ambiguity issues, and allows you to use keywords as variables, as well as using function names as variables without being confusing. The $ dollar sign prefix is like the () bracket suffix of functions - it serves to allow more possibilities, reduce ambiguity, and make code generally more readable.
While what you say is true, what would be used for string concatenation? The ambiguous + plus sign which would be equally as annoying as the + plus sign in JavaScript, or would you use something like the “&” character which requires two key presses? For the web, which is what PHP is designed for, string concatenation is quite important, and hence you wouldn’t want to increase the verbosity and clarity of string concatenation simply to reduce the verbosity of object accessors.
Good points 
Does PHP 6 take advantage of Multi Cores CPU?
I am always worried about depreciation, because really… being updated sucks haha
Deprecation is a non-existent problem as far as I’m aware. I’m pretty sure you can run multiple php version side-by-side without any issues. For this reason, I don’t see why backwards compatibility is so critical.
I don’t believe so. Honestly though, it doesn’t need to. As far as I’m aware, Apache will process concurrent requests in separate threads, and hence as a result, separate PHP instances/threads. I don’t know the details or requirements though; e.g. whether or not PHP needs to be an apache module or running in CGI. By the way, PHP isn’t meant to be a heavy lifter, so multi-threading isn’t really in the PHP domain as such. Mind you, sometimes asynchronous calculations can be handy for other reasons.
The ‘+’ operator actually makes the most sense, especially in a loosely typed language like PHP. From a syntax perspective, ‘+’ means “add this and this together”. Currently, you need to know whether a variable is a String or an Integer to determine which operator to use to combine two variables, whereas with a more powerful ‘+’ operator, the possibility would be open for the syntax
$var1 + $var2;
to be valid no matter the circumstances. While I personally am generally in favor of more type strictness, not less, this particular example seems to argue in favor of the general feelings towards dynamic typing which I’ve heard espoused by most of the “higher ups” in PHP development.
PHP’s use of ‘.’ to add strings is very valuable, But I do agree I’d rather have seen it used more traditionally. If I was around to make a suggestion at the time I would have suggested using # for string addition instead of it’s current use as the PERL style comments marker. No language needs 3 ways to start mark comments.
BTW, you can’t use & – That’s the bitwise and operator.
But I don’t think PHP can go back across that bridge.
I have typed up fairly large posts on this before, but I don’t have any faith in these ideas being entertained. In brief they are.
- Legacy Namespace to contain the existing functions, and a new set of namespaces with all functions named in a clear, concise and predictable manner. The legacy namespace would start enabled in the php.ini that ships but can be turned off or included like any other namespace.
- Variables as Objects: That is any string would have $myString->explode(‘,’) as a method. Arrays would include the methods for their manipulation.
- Method chaining: Linked to the above.
- Strict and Tolerant Variables: Currently all variables are scalar - they can change datatype at a moment’s notice. That behavior is a boon to beginners and a pain in the tail for veterans. Tolerant variables have a set datatype and convert anything assigned to them to that datatype on the fly. Strict variables throw an exception when an attempt is made to assign a value not matching their datatype to them.
- Functions that throw exceptions: Currently many PHP functions return false on failure when throwing an exception would be more appropriate. This is particularly egrarious when the function could return a value logically equal to false - off the top of my head strpos can return 0 quite often. Since changing legacy function behavior would be a pain this goes hand in hand with suggestion #1
I could add more, but those would take long enough to implement and would constitute enough of a paradigm shift to call the result version 6
There already is method chaining.
class ChainTest
{
public function one () {
echo "One; ";
return $this;
}
public function two () {
echo "Two; ";
return $this;
}
}
$t = new ChainTest;
$t->one()->two(); # One; Two;
Could you elaborate on this idea a little? Throwing an exception wherever current functions return FALSE/NULL (and throw E_*) seems a little overboard: to have execution of the script halt and go straight to the appropriate catch (or global handler) would be more than tiresome. Would, for example, a DeprecatedException be thrown where currently E_DEPRECATED is and if so, can I stick with the legacy namespace? (:
I have to agree with that. An exception is supposed to mean something went so wrong that the normal execution of the program needs to stop. Asking for the position of a substring in a string, asking for the next chunk of data from any kind of stream resource and reaching the end of the stream… these return false and you check for it. It’s a well defined behavior, not an exception to normal behavior.
Personally, I don’t mind the dot operator being used for concatenation, but I do agree that “#” being used for comments was unnecessary. If “#” were free for concatenation, I wouldn’t mind that, but I don’t think “+” would be all that great of an idea, considering PHP’s loose and dynamic typing (ECMAScript, for example, does exactly this).
Legacy Namespace to contain the existing functions, and a new set of namespaces with all functions named in a clear, concise and predictable manner. The legacy namespace would start enabled in the php.ini that ships but can be turned off or included like any other namespace.
That seems an interesting idea. PHP’s standard library is quite a mess in this regard.
Variables as Objects: That is any string would have $myString->explode(‘,’) as a method. Arrays would include the methods for their manipulation.
Personally, I’m not a fan of this idea. I just don’t see a compelling enough reason to make everything an object. Perhaps I’m just missing the point.
Strict and Tolerant Variables: Currently all variables are scalar - they can change datatype at a moment’s notice.
That’s not what scalar means. All variables are not scalar:
$a = array('foo','bar'); // aggregate type
var_dump(is_scalar($a));
// bool(false)
That behavior is a boon to beginners and a pain in the tail for veterans.
I’m still perfectly fine with this behavior.
Tolerant variables have a set datatype and convert anything assigned to them to that datatype on the fly. Strict variables throw an exception when an attempt is made to assign a value not matching their datatype to them.
This is an interesting idea. However, I feel like it would work better only if PHP gave more control over scoping, otherwise this might get confusing, since you’d have to track down the declarations of variables more often.
I could add more, but those would take long enough to implement and would constitute enough of a paradigm shift to call the result version 6
Interesting ideas. 
Bzzt.
Yes, you can call methods like that, but it isn’t true chaining because function two doesn’t receive any argument from function one. Method chaining example from prototype… (jQuery would look pretty much the same).
$(‘someID’).down(‘li:first-child’).hide.().up(‘ul’).down(‘li.last-child’).style(‘newstyling’);
And so on. In method chaining you are able to call a method on the returned object of any method. PHP allows you to call multiple functions in order on the same object using a similar syntax, but it isn’t method chaining.
Functions should only return one and only one datatype. If they cannot return that datatype that is an exception. Try/catch syntax exists for a REASON – to avoid ambiguous responses from functions.
Besides, this change in behavior is one of the reasons for implementing this idea at the same time a legacy namespace is created. The existing functions in the legacy namespace all work EXACTLY like they did in PHP 5.x. How the new functions outside the legacy namespace would work in PHP 6 is based on best practice, not their historical setup. Note that the names don’t even need to match
str_pos is a good example. It’s replacement in my mind would be bound to the string object that would handle all strings like in javascript or java. Hence having the str_ prefix in the name of the method isn’t necessary, and pos isn’t a good method name. “find” is though, which is what the method is trying to do - find the position of a string within the current string and if found return that position. To wit:
str_pos($string, ‘search’);
is replaced by
$string->find(‘search’);
This approach also solves the haystack/needle dilemma present throughout PHP.
Method chaining comes into play in that $string->find will return a string. If we needed to split the string up we could use
$string->find(‘search’)->explode(‘,’);
Then we can sort the resulting array…
$string->find(‘search’)->explode(‘,’)->sort();
That’s what method chaining looks like and it’s only possible if the base variables are all objects of some type. It is EXTREMELY powerful since if the functions are named right the construct reads like a sentence.
Implementing this on existing functions would break backwards compatibility. Applying them to different functions in a new namespace however wouldn’t cause any issues since existing code would use the legacy namespace.
Presumably that line would generate a BadMethodCallException, since the find method would return an Integer (else, you’re not really finding the position at all, right?): how would explode (assuming it is a String method) work with Integer objects?
Off Topic:
find is IMO an even worse method name than color=#993366pos[/color], at least the latter represents the purpose of the method/function rather than some generic verb form.
Then I’ll give you a second example that is closer to hows JavaScript/jQuery do it.
class ChainOne
{
function __construct ( $context = null ) {}
function one () {
echo "One; ";
return new ChainTwo( $this );
}
}
class ChainTwo
{
function __construct ( $context = null ) {}
function two () {
echo "Two; ";
return new ChainOne( $this );
}
}
$t = new ChainOne();
$t->one()->two(); # One; Two;
Everything is an object in JavaScript making it possible for every return to have that appearance. With the right implementation it can be done in PHP.
Here’s another good example of method chaining in php
http://stereofrog.com/blok/on/080605
The examples don’t do it any justice.