Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:22301
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <1fc601c643aa$68c46300$6402a8c0@foxbox>
Reply-To: "Steph Fox" <steph@zend.com>
To: <internals@lists.php.net>, "Zeev Suraski" <zeev@zend.com>
References: <7.0.1.0.2.20060309124054.06c31238@zend.com>
Date: Thu, 9 Mar 2006 20:50:57 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="Windows-1252";
	reply-type=response
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Give the Language a Rest motion
From: steph@zend.com ("Steph Fox")

> I'd like to raise a motion to 'Give the Language a Rest'.

Tired inbox? :)

> 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.

I think that's a Good Thing[TM]. Today's cutting edge technology can easily 
become tomorrow's partially-used banana in the pocket of history. Remember 
the transputer?

> 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.

TBH I'd say _generally_ this happens anyway. There isn't a lot of argument 
over 'edge case' changes, although there might be a number of requests for 
them (the perennial issue of memory usage in long-running CLI scripts 
springs instantly to mind). It's pretty rare to see anything new go into the 
Engine that comes under the heading of 'general-purpose language' rather 
than 'language for the web'.

> 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.

We usually have you and Rasmus rather than a mechanism :)  But let's assume 
we didn't, let's say you wanted to drop out of PHP development altogether 
and go raise chili peppers or whatever. The obvious thing would be to write 
some charter in stone.

> 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.

This would be the problem when it came to writing some charter in stone. 
Something that seems irrelevant now, might not be so in the future. Sara 
pointed to Unicode and exceptions as being cases in point; I personally 
don't have any vested interest in exceptions, but I know my life's going to 
be made easier by having integral Unicode support, and I know a lot of other 
PHP users are in that particular boat too. If there'd been a 'don't touch 
the Engine' rule writ in stone, would that option even have come under 
discussion? You're basically preventing evolution when you make hard rules.

> 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.

Perhaps there could be just the one hard rule. 'If it's possible to 
implement it as an extension, do so.' There'd be nothing to prevent 
co-opting essential functionality into the core, but also nothing preventing 
fly-by-night technologies from having support in PHP. The biggest problem 
there is that it doesn't give webhost users a fair crack because changing 
hosts means you risk losing a package or two; and the ability to write 
portable applications is affected in the same way. But this isn't about the 
language itself any more...

> 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