Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66068
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.02.1302201817350.5312@whisky.home.derickrethans.nl>
References: <alpine.DEB.2.02.1302201817350.5312@whisky.home.derickrethans.nl>
Date: Wed, 20 Feb 2013 20:10:34 +0100
Message-ID: <CAEZPtU6CdbM3hRiKMEfdG-gPNETm+LVLCzvsW4aaGZwEwwdc+w@mail.gmail.com>
To: Derick Rethans <derick@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0139ff3079d4f804d62cb6f9
Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd)
From: pierre.php@gmail.com (Pierre Joye)

--089e0139ff3079d4f804d62cb6f9
Content-Type: text/plain; charset=ISO-8859-1

I would also say it us time for us to get back in sync with the communities
needs. I am not talking about the last days RFCs but in general.
On Feb 20, 2013 7:19 PM, "Derick Rethans" <derick@php.net> wrote:

> Looks like it is time to forward this email from 2006 again:
>
> ---------- 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
>
> I'd like to raise a motion to 'Give the Language a Rest'.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Zeev
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--089e0139ff3079d4f804d62cb6f9--