Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66080
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain strojny.net from 46.4.40.248 cause and error)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
In-Reply-To: <alpine.DEB.2.02.1302201817350.5312@whisky.home.derickrethans.nl>
Date: Thu, 21 Feb 2013 00:15:19 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID: <678597E6-E3A8-42E0-8DFC-F8382C9DFB41@strojny.net>
References: <alpine.DEB.2.02.1302201817350.5312@whisky.home.derickrethans.nl>
To: Derick Rethans <derick@php.net>,
  PHP Developers Mailing List <internals@lists.php.net>
Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd)
From: lars@strojny.net (Lars Strojny)

As a general reply: I=92d 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=92t =
even expect


Let=92s 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.


=85 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=92t 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=92s a good thing. We need to continuously =
adapt. What=92s true for software projects is true for languages: stop =
improving actually reduces its value over time.

cu,
Lars

Am 20.02.2013 um 19:18 schrieb Derick Rethans <derick@php.net>:

> Looks like it is time to forward this email from 2006 again:
>=20
> ---------- Forwarded message ----------
> Date: Thu, 09 Mar 2006 12:57:32 +0200
> From: Zeev Suraski <zeev@zend.com>
> To: internals@lists.php.net
> Subject: [PHP-DEV] Give the Language a Rest motion
>=20
> I'd like to raise a motion to 'Give the Language a Rest'.
>=20
> Almost a decade since we started with the 2nd iteration on the syntax =
(PHP 3),
> and 2 more major versions since then, and we're still heatedly =
debating on
> adding new syntactical, core level features.
>=20
> Is it really necessary?  I'd say in almost all cases the answer's no, =
and a
> bunch of cases where a new feature could be useful does not constitute =
a good
> enough reason to add a syntax level feature.  We might have to account =
for new
> technologies, or maybe new ways of thinking that might arise, but =
needless to
> say, most of the stuff we've been dealing with in recent times doesn't =
exactly
> fall in the category of cutting edge technology.
>=20
> My motion is to make it much, much more difficult to add new =
syntax-level
> features into PHP.  Consider only features which have significant =
traction to a
> large chunk of our userbase, and not something that could be useful in =
some
> extremely specialized edge cases, usually of PHP being used for non =
web stuff.
>=20
> How do we do it?  Unfortunately, I can't come up with a real mechanism =
to
> 'enforce' a due process and reasoning for new features.
>=20
> Instead, please take at least an hour to bounce this idea in the back =
of your
> mind, preferably more.  Make sure you think about the full context, =
the huge
> audience out there, the consequences of  making the learning curve =
steeper with
> every new feature, and the scope of the goodness that those new =
features bring.
> Consider how far we all come and how successful the PHP language is =
today, in
> implementing all sorts of applications most of us would have never =
even thought
> of when we created the language.
>=20
> Once you're done thinking, decide for yourself.  Does it make sense to =
be
> discussing new language level features every other week?  Or should =
we, perhaps,
> invest more in other fronts, which would be beneficial for a far =
bigger
> audience.  The levels above - extensions to keep with the latest =
technologies,
> foundation classes, etc.  Pretty much, the same direction other mature =
languages
> went to.
>=20
> To be clear, and to give this motion higher chances of success, I'm =
not talking
> about jump.  PHP can live with jump, almost as well as it could live =
without it
> :)  I'm talking about the general sentiment.
>=20
> Zeev
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20