Hello Sara,
First, thank you for the hard work. I have started to work on it few
days ago as suggested in [1]. You have been faster than me ;-). Good job!
On 23/07/2014 00:22, Sara Golemon wrote:
On Tue, Jul 22, 2014 at 12:50 PM, Sara Golemon <poll...@php.net> wrote:
This document is meant for PHP, and PHP should be the steward of it
going forward, so we (as in PHP) should start looking at good ways to
keep it up to date and revise it over time.
Some folks in IRC asked for clarification of this point.
FB isn't looking to just throw this over wall saying "HERE'S THE FINAL
DOCUMENT, HAVE A NICE DAY, GOOD BYE!". What we're planning to release
next week is more like a pre-1.0 draft which will probably need a lot
of work before anyone is willing to call it final, and of course the
document will need to be updated over time to reflect changes in the
language's syntax (e.g. return typehint rfc).
This is a good news. The approach of Facebook is sane as I can see and
this is comforting.
You said your target was PHP5.6. With Pierre Joye, when we talked about
the PHP Specification, we have mentionned to target PHP6 since (i) it
will solve several PHP inconsistencies and (ii) PHP6 requires 2 years to
be released, just like the PHP Specification (approximately).
We're happy to setup the framework for curating that document
(probably as a github project), but don't want to be all controlling
with it, so if the PHP Group as an organization wants to own it and
manage updates to it over time, all the better. If that means FB sets
it up then hands it over, that's an option too. This is the
discussion I'd like to start now, so that we can work out a strategy
for what that looks like.
My idea was to constitute a **PHP Consortium** (yes, the name is classy
but it reflects the reality), responsible to maintain and edit the PHP
Specification. With what members? Members from the PHP Group
(maintainers of php-src), from Facebook (maintainers of HHVM), from
HippyVM, from JPHP etc. and from others important projects (e.g.
Symfony, Zend etc.), just like the PHP Group does with the RFC votes.
What will be the size of the PHP Consortium? I don't know. Having more
than 100 persons, even qualified, would not be a good idea. A process
must be sketch to propose, discuss and accept RFC, features etc. The
group responsible to validate RFC will be the PHP Consortium. This is
not a technical position, but a “language-semantics” position, in order
to avoid conflicts between different vendors (VM mainteners).
I am wondering whether it is possible to adopt an approach similar to
the W3C: several people working “punctually” on a feature. On one side
we have authors, and on the other side, we have “commenters”. The
workflow is pretty efficient also:
* writing a proposal,
* discussing,
* trying different implementations,
* collecting feedbacks from the users, and finally,
* validating it.
We should not met the issues encountered by the W3C and HTML vendors
because the rate of releases is not the same (fortunately!). Another
source of inspiration can be the process of the ECMAScript language.
If folks have comments on the one chapter I uploaded, I'd say start
with emails to the list or me directly and I'll pass them on.
Please, send me the first chapter :-). I have written specifications for
two languages, my skills can be interesting (this is why I have started
[1]).
That
should be considered a short-term solution though. Ideally we'll have
something in a collaborative format next week that folks with existing
karma can contribute to more directly.
Several people have proposed Github, markdown etc. From my point of view
and experience, this will be insane to manage. If everyone can make a
proposal, this will lead to a lot of noise. PHP allows *some* users to
write RFC. If someone would like to see a new feature, it has to
approach someone with a higher karma/rights or to join the ML
(mailing-list) of the PHP Consortium. Also, about the format, we should
use an advanced one (so it excludes markdown, sorry guys :-)).
Finally, a lot of questions remain open, like:
* What version numbers for the specification? Will they follow the
versions of php-src (the “historical implementation”, haha</trolling>)
* Will the PHP Consortium be splitted into several groups according
to the specification's chapters (for example: the stream part, the
runtime part, the security part etc.)
* Will a test suite to check the conformance of an implementation to
the PHP Specification be provided?
* What are the goals of the PHP Specification? I mean: What are the
subjects? Will it include the extensions, or the definition of extensions?
Maybe I have missed this information but why Facebook is keeping the
sources of the PHP Specification private for now? I'm not judging, just
asking :-).
Again, really great work. Thank you!
Best regards.
[1] http://marc.info/?l=php-internals&m=139565259319206
--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/
PhD 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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
