On Sep 11, 2013, at 15:52 , Terence Copestake <terence.copest...@gmail.com>
wrote:
> (.. ) a concern
> brought up repeatedly both here and in various blogs is the lack of
> direction or vision. There's a conflict between people who want to keep PHP
> simple and accessible and people who want to make PHP into a professional
> programming tool/environment, complete with all bells and whistles. With
> everyone wanting something different and having different ideas on who the
> target users are, what PHP's responsibilities and concerns should be, etc.,
> it's going to be the classic struggle of trying to be everything for
> everybody all at once.
Won't solve the perceived lack of vision, but the conflict could potentially be
solved by modeling php language standardization after how they do it at Ecma,
w3c or iso.
For instance: Let php-internals be as is, Internal stuff in PHP engine and
announcements of rfc's for it, but move out the organization of standardizing
the language.
1. The people involved in standardization should be representatives of the
different implementations of PHP language.
2. Accepting changes to the language would requirer that at least one
implementation have it working behind a compile/runtime flag*
3. Language Tests should be shared and be part of the standardization effort
4. The PHP language standardization body should always allow some variation on
how much a implementation helps the user by default
# Example: Argument and return type hinting**
Specification on this can define two modes of operation:
1. Fatal error on wrong type
2. Strict error on type conversion, and Fatal error on type conversion
with data loss
HPHP could then use mode 1 by default, while PHP uses 2 by default (and 2
with strict errors disabled in production).
This was not intended as a flame, best regards
André R.
eZ Systems
* For anyone involved in web development you might know how messy css vendor
prefixes made the web, forcing them to be behind compile/runtime flags would
avoid this
** Just an example, ignore the details please
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
