Here is a counterpoint to that expressed by Lars. Many if not most
shared hosting providers don't offer PHP 5.4 yet. Ditto many
enterprises have yet to adopt it. The main reason? I think its that
old Backwards Compatibility issue that has been discussed heavily on
this DL.
When major apps like mediaWiki break with a new release of PHP (see
http://www.mediawiki.org/wiki/Compatibility, and this is quite typical),
upgrading PHP versions represents a major headache for both hosting
providers and larger enterprises that want to maintain standard
infrastructure build templates, as each none-BC PHP upgrade represents a
major cost in either loss of customer satisfaction or IT investment for
little or no tangible business benefit.
New features are often nice for the app developer, so the result is that
they then get used by apps development teams, and the provider or
infrastructure team then has to manage the ripple effects on a complex
infrastructure permitted configuration matrix across hundreds or
thousands of apps.
I am not saying that the PHP dev team should freeze PHP, but what I am
suggesting is that the PHP team should also consider the compatibility
impacts across versions so that enterprises and hosting providers who
have adopted PHP can control their through-life maintenance costs.
There are things that the PHP team could do to help mitigate this issue
-- for example producing standard templates so that, say PHP 5.3, 5.4
and 5.5 based apps can coexist and perform (e.g. with APC or O+) on the
*same* Apache2 (or nginx, ...) stack.
Change is good, but too much change too fast without regard to the cost
consequence will ultimately alienate the CIOs and CTOs who set platform
policies.
On 20/02/13 23:15, Lars Strojny wrote:
As a general reply: I’d like to disagree, and here is why. Yes, we should not
let half baked features in but we need to add more and more features, also
syntax wise. For three reasons:
- Parity/expectations/me too: so you can do that in PHP as well
- Expressiveness: allow better ways to express the same idea in more concise
ways
- Innovation: bring unexpected features to the language people didn’t even
expect
Let’s recall a few of the latest additions:
- 5.3: namespaces. Provided the foundation for awesome stuff like PSR-1,
which in turn provides the foundation for the even more awesome stuff composer
is.
- 5.3: goto. A good thing we can do it. I'm not sure for what exactly but I
am sure there is somebody out there :)
- 5.3: Closures, huge thing for us, a matter of parity to other languages.
Really changes the face of a lot of APIs (see e.g. Doctrine transactional(),
the whole micro framework movement, React)
- 5.4: Closures 2.0 with $this binding. Honestly, without it, Closures are a
little meh. But it was good we waited and got it right.
- 5.4: Short array syntax. A parity/culture issue.
- 5.4: Traits, I am happy we got horizontal reuse right
- 5.4: array dereferencing. Very small but useful. To me it feels more like a
bugfix
- 5.4: callable type hint. Small change with a huge impact
- 5.5: Generators, also a matter of parity and a matter of awesomeness
- 5.5: ClassName::class syntax. A really good improvement to the overall
usability of namespaces. Just imagine how much shorter unit test setUp()
methods will become
What we have on our list that, from my perspective, will sooner or later hit us:
- Property accessors in some form or another: a lot of people seem to like it.
- Annotation support: we would have a lot of customers for it.
- Autoboxing for primitives. Allows us to fix a lot of problems in
ext/standard.
- Unicode. Obviously.
- Named parameters. A recurring topic might be a topic worth digging deeper.
- I'm positive the Generics discussion will arise at some point again.
… and these are just the changes on a syntax/semantics level, I'm not talking
about all the awesome technologies (one of which you are working on) we need to
integrate tighter and eventually bundle with core. I don’t believe we should
let our users outgrow the language, quite the opposite, we should grow with our
users and the broader web community, otherwise we will fail. PHP is nowadays
used for tasks it never was intended to be used but that’s a good thing. We
need to continuously adapt. What’s true for software projects is true for
languages: stop improving actually reduces its value over time.
cu,
Lars
