Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73418
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: <5331468E.3090103@hoa-project.net>
Date: Tue, 25 Mar 2014 10:04:14 +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> <5330B375.5030704@sugarcrm.com>
In-Reply-To: <5330B375.5030704@sugarcrm.com>
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")

Hi Stas :-),


On 24/03/2014 23:36, Stas Malyshev wrote:
> Hi!
>
>> All these projects are great for PHP! Yes they are! But, most of these=

>> implementations, interpreters, extensions wrappers etc., are incomplet=
e
>> or propose extra features that is not in the historical interpreter. T=
he
>> 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.
> Having an agreed upon spec would be a nice thing to have. If adopted
> would definitely be useful for some, though I don't see it as absolute
> necessity, it would definitely help in many things.
>
> That said, while I agree that many of the third-party implementations o=
f
> PHP-style languages extend and remove the features, I don't see how
> having standard would help that. It is obvious that those features are
> added or removed for a reason - somebody needed feature X and found it
> hard or unworthy their time to implement feature Y. How exactly having
> document saying "PHP should have Y but not X" would help that?
The specification can also be a common denominator between all the=20
implementations. Something like a subset of the php-src which includes=20
the syntax, the semantics, the tool and the standard library (ext/core,=20
ext/standard, ext/stream, ext/spl and some others). Maybe the standard=20
library of php-src could also be =E2=80=9Crefactored=E2=80=9D (I prefer=20
=E2=80=9Cre-architectured=E2=80=9D) in order to be clearer what is standa=
rd and what is=20
not from the user point of view. However, such points will be clarified=20
during the specification process.


> Even from compatibility POV - i.e. the way to ensure app running on
> PHP-like engine X would run on another PHP-like engine Y - it is much
> more useful to have a good coverage test suite than a document. But
> again, that should not prevent you from creating such a document.
> There's no harm in doing it, and if it comes out good, then a lot of
> good can follow.
Actually, my idea was to provide a specification along with an=20
=E2=80=9Cabstract=E2=80=9D (understand implementation-free) tests suite. =
This is how the=20
majority of projects work. And this will be complementary of the=20
php-src, HHVM etc. test suites (but it would have to be exhaustive, and=20
this is will require a lot of time, that's why I have proposed in [1] to =

split the specification in different modules).


>> Yes it will reveal some leaks in the historical interpreter. Yes the
> I would allow myself some advice here - if you want people here be more=

> excited about this, drop the "historical" word. If you need the special=

> name for the PHP engine developed by the php.net group in order to
> emphasize its distinction, call it "official" or "original" or "php.net=
"
> (that if "the PHP engine" is not enough for some reason). I know it
> looks like nitpicking, but when we're talking both about
> community-building and about defining things, words matter.
Yes definitively :-). In french (my first speaking language), this word=20
does not sound too pejorative, my mistake! Johannes used the term =E2=80=9C=
prime=20
implementation=E2=80=9D which is good also, but =E2=80=9Cofficial=E2=80=9D=
 sounds good enough=20
for me too.

Thanks for the clarrification!


>> If a new interpreter provides a nice feature, then, a discussion can
>> start to update the standard, but if there is no one, which interprete=
r
>> will be chosen by the user? If there is a standard, we can compare
> Nothing prevents one right now from submitting RFC for a nice feature
> that exists in PHP-like interpreter X but does not exist in PHP. Having=

> standard wouldn't change much in that regard.
The specification will define what will be standard and what will not=20
be. For Web technologies, this is exactly the same thing. We have=20
standards/specifications, and implementations. One vendor proposes a new =

features through an implementation and a specification proposal. It is=20
discussed at the specification level and then valided or not. If it is=20
validateed, then other vendors will update their implementation to=20
respect the specification. If it is not validated, then either they=20
review their proposal or they give up or at last they keep it as=20
=E2=80=9Cprivate=E2=80=9D. And this last option is not bad at all: if the=
y need this=20
feature, well, they implement it and that's good. If a user would like=20
such a feature, then it will use this implementation. But if someone is=20
making a framework, a set of libraries, a big tool, that is intented to=20
be used by every PHP user, then, it will develop in regards of the=20
standard/specification. That's how things work. And if a feature in a=20
specification implementation appears to be very attractive for users,=20
then the =E2=80=9Cspecification consortium=E2=80=9D could revise its posi=
tion. This is a=20
living process, made by humans for humans!


>> 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 t=
o
>> Thoughts?
> If you're ready to start such project, go ahead and do it. I personally=

> wish you all the luck.
Thank you. I really would like to start it, maybe in few weeks/months.=20
Things are clear in my head, maybe I could draft something in few weeks.



Regards.

[1] http://news.php.net/php.internals/73417

--=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/