Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73376
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain hoa-project.net from 95.130.10.56 cause and error)
Message-ID: <5330041F.9090809@hoa-project.net>
Date: Mon, 24 Mar 2014 11:08:31 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Thunderbird/30.0a2
MIME-Version: 1.0
To: internals@lists.php.net
References: <532FF7B9.5040700@hoa-project.net>	 <1395653827.9365.9.camel@guybrush>	 <CAEZPtU59+g+YhsAU61u43BPPRoVg77DjUopV59AJiri+SU8b8w@mail.gmail.com> <1395654744.9365.17.camel@guybrush>
In-Reply-To: <1395654744.9365.17.camel@guybrush>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] PHP Specification
From: ivan.enderlin@hoa-project.net ("Ivan Enderlin @ Hoa")


On 24/03/2014 10:52, Johannes Schl=C3=BCter wrote:
> On Mon, 2014-03-24 at 10:42 +0100, Pierre Joye wrote:
>> Agreed on the contributions process, however:
>>
>> Ivan is talking about specifications, an implementation follows a
>> given specification, not the other way 'round. A well written
>> specification greatly simplify documentations, implementation(s) and
>> testing, to name only a few advantages.
> Yes, that's what we do in RFCs. I won't stop anybody from consolidating=

> a base specification, but as everything in this volunteer driven projec=
t
> this depends from people actually doing this, not from meta discussions=
=2E
This is not a meta discussion at all. This is a real discussion because=20
the usage of Computer Science are evolving. Most of languages have a=20
specification: Javascript (with ECMAScript), Python, C, OCaml etc., with =

different interpreters or compilers (respectively SpiderMonkey or V8,=20
CPython or PyPy, gcc or LLVM=E2=80=A6).

The implementation is less and less important, whereas the language is=20
more and more important. This is a reality.


> Also as long as PHP is the PHP reference implementation all things have=

> to be implemented there to be part of the language.
And here is the first conflict. While I deeply agree with you, this may=20
not be how we should work. We should at first create the specification=20
and then secondly provide an implementation that respects this=20
specification. It would be great to see internal@ to be the first=20
interpreter to implement the standard, but this will not be always the=20
case. Another project could propose a new feature along with an=20
implementation in their own interpreter; when the feature will be=20
accepted, then we will implement it in the =E2=80=9Chistorical=E2=80=9D i=
nterpreter.

I think we have to split the language and the implementation, while=20
keeping php-src as the default and (so far) the prime implementation.


>> That being said, I find very disturbing the total lack of interest
>> from historical (from a time pov, not activity) core developers in the=

>> next major version. Most drastic changes around PHP happen outside
>> PHP, many features our users are looking for are implemented outside
>> the core while we keep arguing about the needs of these features. This=

>> is not a good thing.
> In my opinion it is a good thing that PHP is powerful enough to enable
> frameworks etc. to innovate around the core language. The core language=

> has to be a reliable and stable.
Yup, +1. But I think that Pierre was referring to PHP6 features and the=20
weak interest and responses he collected (but I don't want to speak for=20
him).

--=20
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/