Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73381
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 198.187.29.233 as permitted sender)
Content-Type: multipart/alternative; boundary="Apple-Mail=_3D8DC45E-CADC-409D-B43C-8627C6E29C87"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
In-Reply-To: <532FF7B9.5040700@hoa-project.net>
Date: Mon, 24 Mar 2014 15:52:09 +0000
Cc: internals <internals@lists.php.net>
Message-ID: <DD864C7C-6497-411A-9815-36D7662B2846@ajf.me>
References: <532FF7B9.5040700@hoa-project.net>
To: "Ivan Enderlin @ Hoa" <ivan.enderlin@hoa-project.net>
Subject: Re: [PHP-DEV] PHP Specification
From: ajf@ajf.me (Andrea Faulds)

--Apple-Mail=_3D8DC45E-CADC-409D-B43C-8627C6E29C87
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On 24 Mar 2014, at 09:15, Ivan Enderlin @ Hoa =
<ivan.enderlin@hoa-project.net> wrote:

> All these projects are great for PHP! Yes they are! But, most of these =
implementations, interpreters, extensions wrappers etc., are incomplete =
or propose extra features that is not in the historical interpreter. The =
need of a PHP specification/standard is more and more important: =
language syntax, semantics, features, extensions API, etc., must be =
specified in order to see more collaborations and quality tools.
>=20
> We can imagine seeing new contributors on the specification, and =
whatever the implementation, it will benefit to the users and =
developers. Yes it will take a lot of time. Yes it will be difficult. =
Yes it will reveal some leaks in the historical interpreter. Yes the =
language will be more important than the interpreter. But it will give =
us a lead, a path to follow, a goal, and moreover, it will ensure the =
same experience to all PHP users no matter the interpreters they used.
>=20
> If a new interpreter provides a nice feature, then, a discussion can =
start to update the standard, but if there is no one, which interpreter =
will be chosen by the user? If there is a standard, we can compare =
interpreters regarding this standard and not idiotic benchmarks that =
show anything.
>=20
> Finally, I think that internal@ is responsible to start such a =
standardization process because this group has made the historical =
interpreter. In addition, I think that internal@ is also responsible to =
promote this standard and invite other actors to collaborate. These last =
years, PHP has shown a new face, a face of unity and pragmatism (new =
release process, RFC debates etc.). Such a standardization process will =
be strong and can really put PHP forward.


I agree, I think PHP needs a specification. For one thing, a reference =
implementation is no real specification. It can=92t be easily consulted, =
and it also means that any reference implementation bug might be =
considered a language feature, which other implementations must have. =
Having a proper specification would mean documentation for users would =
be easier, too. I suppose the specification could become the =
documentation.

However, care would need to be taken when drafting it to make sure that =
we are careful to reflect PHP as it actually is (i.e. how the reference =
implementation behaves), and not necessarily PHP as it ought to be. If =
PHP in practise does not match the specification, it may be useless.

PHP=92s current reference implementation and its behaviour are wildly =
inconsistent and, frankly, a bit of a mess. If we were to specify PHP, =
we should do so after a major cleanup, say in PHP 6. At the moment, just =
specifying the ++ operator would require a page.
--
Andrea Faulds
http://ajf.me/





--Apple-Mail=_3D8DC45E-CADC-409D-B43C-8627C6E29C87--