With PHP 6 deep in development, and with many likely features out in the open, what are some of the features you’re most looking forward to, and additionally, what are some features you wish were being implemented in PHP 6, but likely won’t be?
To get the ball rolling, the two new features that will affect me the most will be…
Traits - assuming they will in-fact make it into PHP 6.
Getters/Setters - One of those features that should have been part of PHP 5’s initial OOP improvements. Getters and setters I believe are crucial for dynamic OOP languages, more so than statically typed languages. Especially in PHP where functions/methods rely on correct data types. If this feature somehow gets left out of PHP 6, I’ll be very disappointed and may lose complete hope for the future of PHP 6 - that’s how important I think this feature is.
As for things I wish from PHP 6 which won’t be implemented, the main thing I can think of is making all PHP extensions object-orientated. It would be a mammoth job and would no doubt break every piece of PHP code written, but seriously, any functions which require the use of “resources” (like file functions, ldap, curl, etc), are begging to be implemented as objects. This is mentioned in the other recent PHP 6 thread: http://www.sitepoint.com/forums/showthread.php?threadid=650472
I haven’t been able to find a final list of features being implemented in PHP 6, so if anyone knows of such a list, please link to it.
Other than better Unicode support, I’m cool with the PHP 5.3 branch. I’m not really looking forward to anything new, and don’t expect to be using PHP 6 for some years unless there’s a compelling performance change.
Dan, do you have much experience with other modern programming languages? whether it be a lisp-type language like Clojure, or something like C#? I ask because as someone who has recent experiences with such languages, it highlights the major short-falls of PHP. To me, the good thing about PHP isn’t the language, because let’s face it, it’s a bit of a mess - any languages that goes from procedural to OOP will be filled with nasties. The good thing about PHP I believe is the fact that is dynamically typed, has no compile stage, and is easy to setup. These few things are the biggest things I miss when working in other languages/environments. It’s just suited for the needs of the web, which is exactly what PHP is for. As a client-side language for desktop applications, it would be horrible.
What if PHP 6 deprecated A LOT of existing code. Would that encourage you to make the move to PHP 6 sooner, to ensure you’re not wasting time writing PHP 6 incompatible code, or would that make you much more resistant to change over?
I wrote C#.NET working for Microsoft, Java working for Math Forum, C++ working for DuPont, genetic algorithms in Python, shopping carts in Perl, a chat server in Scheme. Haven’t just used lambdas and closures but wrote a language and interpreter to implement them. I’ve written as low level as operating system kernels with some bit mashing in ASSEMBLY and as high level as JavaScript UIs.
Yep, PHP is a bit of a mess, especially the libraries. But I am quite happy with it anyway. I just get things done with it, and it has all the power I need. If PHP weren’t here I’d be using Python, but it is, and I know how to optimize the stack for performance, not so much with Python yet.
I tend towards the practical over the aesthetically elegant designs, so never had an interest in something like Ruby on Rails or trying to build a real webapp in something LISP-based. PHP’s ugly but I like it anyway.
I would like named parameters, such that if you have a function
function foo($a=2, $b=3, $c=4, $d) {
// so somethin
}
You can call it like
foo(d=5)
Or some similar syntax that indicates that parameter “d” should get value 4.
Would be handy in this situation because “a”, “b” and “c” already have default values assigned.
I do however look forward to anonymous functions. I know PHP 5.3 already has them, but I’m still on 5.2.8 since none of my hosts support 5.3 yet.
Always hated the create_function() function, gives you too much rope to hang yourself.
While named parameters could certainly be beneficial, it’s also likely to be used incorrectly and result in poor design decisions. If a function or method has a need for named parameters, it’s normally a good indicator that the function/method is trying to do too much, or has been poorly designed. Such situations call for a revision and usually result in separating out functionality into multiple functions/methods. In that rare circumstance however where there really is a valid use for named parameters, than an array will probably better serve the need.
While I agree, that would be nice, such a situation where you need to use that functionality is normally an indicator of a slightly flawed object or function design. If it’s relatively likely that a caller will only need a single value of a returned array, then either the function/method should be revised and possibly split into two, or, the function should provide a means to return a single element. With that in mind however, it would be a good if there was a universal syntax for accessing values as if they were assigned to an array. Curly braces would be a good solution, as they currently serve a similar purpose for variables, e.g.
$i = 1;
${"var".$i} = 2; // Sets $var1 to the integer value, "2".
This is currently in PHP, so it would be natural to assume that {getArray()}[2] would perform a similar function. Alternatively, it would be a good interim fix to add a new array function such as array_index(getArray(), 2).
One thing I things I think PHP also suffers from, is “no-right-way” syndrome; I just made that up, so let me explain. This syndrome exists in many languages, where a relatively common problem has no single/preferred/proper solution, and instead requires poor and usually verbose work-arounds, or equally as bad, developers implementing their own “right-way” solutions, which often results in a lot of variance between open-source applications, frameworks and libraries. Setters/getters are a good example of that. Lack of traits is another example; there’s simply nothing that can really fill the void of traits, except by violating DRY or writing awful and complex code.
I feel somewhat similarly to Dan Grossman, with regard to PHP 6, especially the improved Unicode support. However, in general, I don’t feel the introduction of new features would be very helpful for me.
Contrary to some, I rather like PHP’s syntax. I find its level of expressiveness suits me well and oftentimes feels like C. While I generally prefer stricter typing, say, like Python’s, I still find I can accomplish most tasks very efficiently in PHP.
I disagree. I don’t find the language itself intrinsically prohibitive for desktop application programming. However, the level of PHP’s implementation would be problematic for certain applications. However, if you have/write a well-designed GUI API for your implementation of PHP, I think it’d be pretty nice for some applications.
Sometimes, it’s legitimately helpful for the language designers to provide built-in functionality for addressing design decisions, but a line must be drawn somewhere. Language designers can’t accommodate everyone. Forcing language features or designs that just don’t fit is often a sign that one needs to rethink their fundamental approaches. Perhaps I’ve just never come across a case where I truly thought there was “no-right-way”. When I feel that way, I generally credit it as a fault on my end.
My point is, PHP lacks the functionality required by rich/thick clients and applications, like those commonly found on the desktop. It’s lack of multi-threading and static typing are good examples of why PHP is really only suitable for front-end web development, which is essentially 95% of web development (i.e. all those which don’t require heavy lifting). I mention static typing because while there are successful dynamically typed languages for the desktop, PHP’s implementation of dynamic typing is just too loose (e.g. no type hinting or argument conditions, with the exception of classes and arrays).
This, this, a thousand times, this. I have difficulty ever thinking of any language as robust if it doesn’t implement a native String class.
I also would like to see the possibility to move away from the arrow (->) to the dot (.) for methods/properties/whatever. I’m not generally super lazy about typing, but that’s one that I’d really appreciate.
It’s all just the “trunk”: the bleeding edge where things can get added or removed at any time (like the previous major unicode work). With change to trunk has come a renewed vigour to get stuck in and move forward. The number assigned to what becomes of this code remains to be seen.
I’d assume you would like native objects for other scalar types too? (: Can you explain what draws you to having such native object(s) over their current form?
As for the comments on changing -> to . is there any functional reasoning for that or do you guys just see that latter as “prettier”?
I think it would clear the path to finally sort out the whole $needle, $haystack debacle. Much like the DateTime object in 5.3, it would allow users to use a cleaner interface at their discretion but still maintain backwards compatibility for the others.
Not really looking forward to anything. Anything from PHP 5.2 and above is good enough for me. Just better unicode support, as already pointed out, would be nice.
I don’t really think rewriting all extensions to oop would make sense. I say write any future extensions in oop but leave the current ones as is not to break backwards compatibility. Don’t change if it’s not broken…
It’s just prettier, and avoids confusion when you switch a lot between PHP and for example Java.
For the same reason I’d like to say goodbye to the $ for variables.
For me, it’s primarily an ease of typing issue. ‘.’ is much simpler to type (one third the key-presses) than ‘->’, which requires a lot of moving by a single hand, and concurrent key presses. Additionally, it is a little prettier, too.
