Live data from Hacker News

What PHP 5.5 might look like

nikic.github.com

101–110 of 139 posts

Re: What PHP 5.5 might look like

#102

> PHP 5.5 will no longer support Windows XP and 2003. Those systems are around a decade old, so PHP is pulling the plug on them. Given the recent threads about planned obsolescence (Apple) and OS fragmentation (Android) I'm curious what is missing from XP/2003 that is part of Vista+. Are there still exciting things happening in the world of OS APIs that are relevant for server software? Or does this just mean that no…

I can foresee them making a turn on this decision and continuing to support XP until developers actually stop using XP anymore. XP isn't going away anytime soon.

It was nice to see short tags "<?" coming back in 5.4. Before that, they used to say, don't use short tags, it's dangerous, breaks things. But users resisted it, and every ISP kept it open. And now from PHP 5.4 short tag is ON, regardless of whether one setts it On or Off in php.ini.

Re: What PHP 5.5 might look like

#103
post #102

> PHP 5.5 will no longer support Windows XP and 2003. Those systems are around a decade old, so PHP is pulling the plug on them. Given the recent threads about planned obsolescence (Apple) and OS fragmentation (Android) I'm curious what is missing from XP/2003 that is part of Vista+. Are there still exciting things happening in the world of OS APIs that are relevant for server software? Or does this just mean that no…

I can foresee them making a turn on this decision and continuing to support XP until developers actually stop using XP anymore. XP isn't going away anytime soon. It was nice to see short tags "<?" coming back in 5.4. Before that, they used to say, don't use short tags, it's dangerous, breaks things. But users resisted it, and every ISP kept it open. And now from PHP 5.4 short tag is ON, regardless of whether one sett…

No actually, as of 5.4 <?= is always available. <?= and <? are not the same thing.

Re: What PHP 5.5 might look like

#104
post #4

Earlier quoted context omitted.

Better than parameter skipping would be named parameters so you could just do: function foo($a, $b="10", $c="5", $d="3") { /* .. */ } foo(5, $c="10"); That way $a == 5, $b == "10", $c == "10", and $d == "3". Much better and cleaner syntax in my opinion and a lot of other languages support something similar.

The problem with that is it's already valid syntax with a different meaning. function foo($a, $b = "10", $c = "20") {} foo(1, $c=20); var_dump($c); // int(20) The syntax would have to be unambiguous. Perhaps: foo(5, c: 30) or foo(5, $c: 30); or foo(5, $c => 30) or something like that...

Maybe I am missing something but never seen that in practice (the 'foo(1, $c=20)' bit), that's a really odd way to initialize a variable. Wouldn't mind if they change it, so that it breaks (with a warning or error). Or have you seen this syntax a lot?

Re: What PHP 5.5 might look like

#105
post #77

Earlier quoted context omitted.

One major disadvantage with so many functions is the cluttered global namespace[1]. PHP only added namespaces in 5.3.0 and can't modularize their globals into namespaces without causing massive backwards compatibility problems. PHP is stuck with a polluted global namespace, I'd be wary of adding more. Mind you, I'm well aware that this feeling could just be as I'm primarily a Python coder -- in PHP, you perform array…

>PHP only added namespaces in 5.3.0 and can't modularize their globals into namespaces without causing massive backwards compatibility problems. PHP is stuck with a polluted global namespace They could do what Python did for 3.0, and make a tool similar to Python's 2to3 that replaces global namespace references.

That sounds like a disaster. I don't think anyone wants to follow Python's lead on breaking backwards compatibility without a very good reason. A much better reason than a cluttered namespace.

Re: What PHP 5.5 might look like

#106

Is PHP JIT at least on the roadmap?

As far as I am aware, it is under consideration for Zend Engine 3 / PHP6. But certainly not for 5.5, and probably not in the 5.x series at all. Though how many 5.x releases are left is anyone’s guess, personally my crystal ball tells me we will get 5.6 followed by 6. My crystal ball also says we will all have flying cars by now.

Re: What PHP 5.5 might look like

#107
post #6

The introduction of list comprehensions is nice and should replace numerous functions. For example, I'm not sure why they're adding the array_column function into PHP 5.5 at the same time as list comprehensions as: $names = array_column($users, 'name'); // is the same as $names = [foreach ($users as $user) yield $user['name']]; The only possible reason would be due to a significant speed difference, but I'd suggest i…

array_column looks like a half-assed version of map. Looks like PHP hasn't changed a bit. Functions that do half of what their supposed to do and have odd names that depart wildly from industry standard language.

Re: What PHP 5.5 might look like

#108

> PHP 5.5 will no longer support Windows XP and 2003. Those systems are around a decade old, so PHP is pulling the plug on them. Given the recent threads about planned obsolescence (Apple) and OS fragmentation (Android) I'm curious what is missing from XP/2003 that is part of Vista+. Are there still exciting things happening in the world of OS APIs that are relevant for server software? Or does this just mean that no…

I believe Visual Studio 2010 and 2012 generate code that imports MSVCRT functions that are not available on Windows 2000 or XP:

https://connect.microsoft.com/VisualStudio/feedback/details/...

https://connect.microsoft.com/VisualStudio/feedback/details/...

Re: What PHP 5.5 might look like

#109
post #67
post #6

The introduction of list comprehensions is nice and should replace numerous functions. For example, I'm not sure why they're adding the array_column function into PHP 5.5 at the same time as list comprehensions as: $names = array_column($users, 'name'); // is the same as $names = [foreach ($users as $user) yield $user['name']]; The only possible reason would be due to a significant speed difference, but I'd suggest i…

I can't say I like the solution for parameter skipping though... I disagree with the author -- many optional arguments is not a problem IMO This is a problem and bad design, because instead of default arguments you can use properties for optional arguments.

Or encapsulate excess arguments in objects that represent the data that needs to be moved around, if possible.

Re: What PHP 5.5 might look like

#110
post #68

I was involved with PHP internals when type hinting came up for 5.3, and helped steer that discussion in some way [1]. It was a truly awful experience - at the time, the internals community was a very negative and poisonousness place. Does anyone still involved know if that has been fixed? [1] oh look, I'm still mentioned in the RFC :) - https://wiki.php.net/rfc/scalar_type_hinting_with_cast

Given that you're involved in this - why add "with cast"? I thought the whole point of the feature, in regards to classes and arrays, is to be absolutely strict about function arguments. Once you start down the path of "well, as long as it's sort of like that," then you might as well accept objects that have toString defined in place of strings. Having worked in a large PHP project for years and trying to get it to a point of letting new developers spin up pretty quickly (and use PHPStorm efficiently), STRICT type hinting is one of the best tools possible!
Post reply on HN