Hello :-),
We see more and more PHP interpreters or compilers out there:
- the historical interpreter [1],
- interpreter from Facebook [2],
- interpreter written for .NET [3],
- interpreter written for JVM [4],
- maybe I forgot some of them.
Also, we see more and more languages that compile into PHP or are
wrappers to create extensions, such as:
- Zephir, a pseudo-language to create extensions [5],
- PHP-CPP, a C++ library to create extensions [6].
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.
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.
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.
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.
Thoughts?
Best regards.
[1] http://php.net/
[2] http://hhvm.com/
[3] https://github.com/DEVSENSE/Phalanger
[4] https://github.com/dim-s/jphp
[5] http://zephir-lang.com/
[6] http://www.php-cpp.com/
--
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/
- the historical interpreter [1],
How is that historic? It is the prime standard with most active
contributors etc.
Finally, I think that internal@ is responsible to start such a
standardization process because this group has made the historical
interpreter.
It is building the reference implementation. If other implementations
add new features they can and they can propose it for inclusion in the
reference implementation by which it becomes part of the language
definition. While old parts of the implementation are only documented in
code and reference documentation form the RFC process provides more
architectural of new features.
johannes
On Mon, Mar 24, 2014 at 10:37 AM, Johannes Schlüter
johannes@schlueters.de wrote:
- the historical interpreter [1],
How is that historic? It is the prime standard with most active
contributors etc.Finally, I think that internal@ is responsible to start such a
standardization process because this group has made the historical
interpreter.It is building the reference implementation. If other implementations
add new features they can and they can propose it for inclusion in the
reference implementation by which it becomes part of the language
definition. While old parts of the implementation are only documented in
code and reference documentation form the RFC process provides more
architectural of new features.
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.
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.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
On Mon, Mar 24, 2014 at 10:37 AM, Johannes Schlüter
johannes@schlueters.de wrote:[snip]
Finally, I think that internal@ is responsible to start such a
standardization process because this group has made the historical
interpreter.
It is building the reference implementation. If other implementations
add new features they can and they can propose it for inclusion in the
reference implementation by which it becomes part of the language
definition. While old parts of the implementation are only documented in
code and reference documentation form the RFC process provides more
architectural of new features.
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.
+1. You have understood me.
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.
I don't know the reason. It is related to the vision/goal of PHP, to the
code? Without an answer to this question, we can't fix it.
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.
I deeply think that a specification will gather people around the same
goal. RFC already do this job, but we need to go further.
--
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/
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 project
this depends from people actually doing this, not from meta discussions.
Also as long as PHP is the PHP reference implementation all things have
to be implemented there to be part of the language.
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.
johannes
On Mon, Mar 24, 2014 at 10:52 AM, Johannes Schlüter
johannes@schlueters.de wrote:
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.
Agreed, but I was not clear. I refer to core features like what we can
find in hhvm, hack, more recently the JVM compiler or similar
projects. Many features which have nothing to do with the engine they
use should have been available in the core since long.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
On Mon, Mar 24, 2014 at 10:52 AM, Johannes Schlüter
johannes@schlueters.de wrote: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.Agreed, but I was not clear. I refer to core features like what we can
find in hhvm, hack, more recently the JVM compiler or similar
projects. Many features which have nothing to do with the engine they
use should have been available in the core since long.
If anybody (being a contributor to a clone or some "user") sees anything
in any implementation that they want to be part of PHP they can under
the RFC process.
If anybody thinks there is need for a specification they can start
writing it and look for help and review.
Statements that something "should" be done by "somebody" won't work in a
volunteer project.
With that this discussion is finished for me. If anybody wants to
reiterate this we can do this off list, not taking time from others with
a meta discussion giving no results.
johannes
On Mon, Mar 24, 2014 at 10:52 AM, Johannes Schlüter
johannes@schlueters.de wrote: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.
Agreed, but I was not clear. I refer to core features like what we can
find in hhvm, hack, more recently the JVM compiler or similar
projects. Many features which have nothing to do with the engine they
use should have been available in the core since long.
If anybody (being a contributor to a clone or some "user") sees anything
in any implementation that they want to be part of PHP they can under
the RFC process.If anybody thinks there is need for a specification they can start
writing it and look for help and review.Statements that something "should" be done by "somebody" won't work in a
volunteer project.
This is exactly my approach. I am starting a thread to discuss about it,
and I don't ask “somebody” to do this, I am just exchanging an idea. I
could be a volunteer to start such a project (in few months), but at
first, I have created this subject to gather opinions.
With that this discussion is finished for me. If anybody wants to
reiterate this we can do this off list, not taking time from others with
a meta discussion giving no results.
Why such a reaction? Did you take my idea as offensive? Why declaring
this subject as “meta discussion giving not results”? We are just
speaking about it for 1 hour ago…
Best regards.
--
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/
Hi Johannes,
On Mon, Mar 24, 2014 at 11:04 AM, Johannes Schlüter
johannes@schlueters.de wrote:
On Mon, Mar 24, 2014 at 10:52 AM, Johannes Schlüter
johannes@schlueters.de wrote: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.Agreed, but I was not clear. I refer to core features like what we can
find in hhvm, hack, more recently the JVM compiler or similar
projects. Many features which have nothing to do with the engine they
use should have been available in the core since long.If anybody (being a contributor to a clone or some "user") sees anything
in any implementation that they want to be part of PHP they can under
the RFC process.If anybody thinks there is need for a specification they can start
writing it and look for help and review.Statements that something "should" be done by "somebody" won't work in a
volunteer project.With that this discussion is finished for me. If anybody wants to
reiterate this we can do this off list, not taking time from others with
a meta discussion giving no results.
Good so as it makes no sense to get into a rhetorical battle, none of
us needs it and I think you pretty much understood what I meant by
"should be done" or about the lack of participation of older
developers in discussions, but blocking things at the voting phase.
--
Pierre
@pierrejoye | http://www.libgd.org
On Mon, Mar 24, 2014 at 10:52 AM, Johannes Schlüter
johannes@schlueters.de wrote: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.Agreed, but I was not clear. I refer to core features like what we can
find in hhvm, hack, more recently the JVM compiler or similar
projects. Many features which have nothing to do with the engine they
use should have been available in the core since long.If anybody (being a contributor to a clone or some "user") sees anything
in any implementation that they want to be part of PHP they can under
the RFC process.If anybody thinks there is need for a specification they can start
writing it and look for help and review.
What would be the process for that? The RFC process covers adding new
features and removing deprecated features.
The documentation process covers documenting how to use certain features.
Neither of these processes seem to be a direct fit for specifying how
certain features should handle undocumented features.
If the RFC process is the correct one to follow for that, that would be
great. From there it would then be up to those want to spend the time
to create the RFC itself and then it would be welcome on this list to
propose/advocate for it?
Note: this same issue has also occurred with gcc. As the Clang
compiler gains popularity, the Clang developers have been running test
compiles of popular open source c/c++ code with it and they have
discovered hundreds of bugs in those projects. Because of
undocumented/broken features in gcc the source for those projects
compiles and runs anyway. Obviously if gcc claims to be a "standards
compliant" compiler then if it is allowing code which is not standards
compliant to compile without generating any warnings gcc is 'broken'.
However, they are naturally reluctant to "fix" a bug which will then
break other people's projects.
Alternative implementations are great for discovering bugs in the
reference implementation.
Gary Mort wrote:
If anybody thinks there is need for a specification they can start
writing it and look for help and review.What would be the process for that? The RFC process covers adding new features
and removing deprecated features.The documentation process covers documenting how to use certain features.
Neither of these processes seem to be a direct fit for specifying how certain
features should handle undocumented features.
Neither process provides a good 'quide' to actually using PHP and it is that
which is missing!
The RFC documentation provides a self contained description of an element of the
language with little reference to how it fits into the whole. This is then used
as the base for the relevant documentation which similarly documents 'a
function' or 'a process' with a greater or lesser level of completeness, but
neither of them provide any 'dovetail' into an overall user guide to PHP.
In many cases 'Undocumented' features appear as comment footnotes, and these
become unofficial guide lines, so something which has not been considered
properly in the original design can become standard by virtue of the fact it
does have some random documentation.
A specification would provide an overview of how to design a PHP application
given all of the - in some cases difficult to understand - new features that are
being added.
I've got to the point where it would be nice to know just what is 'undocumented'
in relation to simply using UTF-8 in PHP5. It would seem that the majority of
peoples use of it is already covered? It is just adding the more complex string
handling IN the core which is missing? But there is not a document that actually
shows where UTF-8 can be used safely at the moment?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
On Mon, Mar 24, 2014 at 10:52 AM, Johannes Schlüter
johannes@schlueters.de wrote: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.Agreed, but I was not clear. I refer to core features like what we can
find in hhvm, hack, more recently the JVM compiler or similar
projects. Many features which have nothing to do with the engine they
use should have been available in the core since long.If anybody (being a contributor to a clone or some "user") sees anything
in any implementation that they want to be part of PHP they can under
the RFC process.If anybody thinks there is need for a specification they can start
writing it and look for help and review.
What would be the process for that? The RFC process covers adding new
features and removing deprecated features.
The documentation process covers documenting how to use certain features.
Neither of these processes seem to be a direct fit for specifying how
certain features should handle undocumented features.
If the RFC process is the correct one to follow for that, that would be
great. From there it would then be up to those want to spend the time
to create the RFC itself and then it would be welcome on this list to
propose/advocate for it?
Note: this same issue has also occurred with gcc. As the Clang
compiler gains popularity, the Clang developers have been running test
compiles of popular open source c/c++ code with it and they have
discovered hundreds of bugs in those projects. Because of
undocumented/broken features in gcc the source for those projects
compiles and runs anyway. Obviously if gcc claims to be a "standards
compliant" compiler then if it is allowing code which is not standards
compliant to compile without generating any warnings gcc is 'broken'.
However, they are naturally reluctant to "fix" a bug which will then
break other people's projects.
Alternative implementations are great for discovering bugs in the
reference implementation.
Hi!
What would be the process for that? The RFC process covers adding new
features and removing deprecated features.
Just start creating it and if the process will be needed, it can emerge
among the people that are doing it. When something that is fit for
review would be ready, we may use this list and the wiki or other tools
to review it (I'd advise to publish it on a platform that allows
comments, such as github or google docs) and then use RFC-like process
to gain acceptance. But first somebody needs to actually do it.
Alternative implementations are great for discovering bugs in the
reference implementation.
Not sure in which way another implementation should be helpful in
discovering bugs in the PHP engine - could you give some examples of
such bugs?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
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 project
this depends from people actually doing this, not from meta discussions.
This is not a meta discussion at all. This is a real discussion because
the usage of Computer Science are evolving. Most of languages have a
specification: Javascript (with ECMAScript), Python, C, OCaml etc., with
different interpreters or compilers (respectively SpiderMonkey or V8,
CPython or PyPy, gcc or LLVM…).
The implementation is less and less important, whereas the language is
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
not be how we should work. We should at first create the specification
and then secondly provide an implementation that respects this
specification. It would be great to see internal@ to be the first
interpreter to implement the standard, but this will not be always the
case. Another project could propose a new feature along with an
implementation in their own interpreter; when the feature will be
accepted, then we will implement it in the “historical” interpreter.
I think we have to split the language and the implementation, while
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
weak interest and responses he collected (but I don't want to speak for
him).
--
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/
* the historical interpreter [1],How is that historic? It is the prime standard with most active
contributors etc.
Historical is not synonym of out-dated. Historical means it is the first
interpreter, that's all.
--
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/
* the historical interpreter [1],How is that historic? It is the prime standard with most active
contributors etc.
Historical is not synonym of out-dated. Historical means it is the first
interpreter, that's all.
historical (adj.)
-
connected with history or with the past
a.
connected with history as a subject of study
b.
used for describing someone or something as they really existed in
the past -
literature: a historical novel, film etc is based on people or events
that existed in the past
http://www.macmillandictionary.com/dictionary/british/historical
johannes
* the historical interpreter [1],How is that historic? It is the prime standard with most active
contributors etc.
Historical is not synonym of out-dated. Historical means it is the first
interpreter, that's all.
historical (adj.)
connected with history or with the past
a.
connected with history as a subject of study
b.
used for describing someone or something as they really existed in
the pastliterature: a historical novel, film etc is based on people or events
that existed in the pasthttp://www.macmillandictionary.com/dictionary/british/historical
Fine. Excuse me Sir. Can we go forward now?
--
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/
"Ivan Enderlin @ Hoa" ivan.enderlin@hoa-project.net schrieb:
* the historical interpreter [1],How is that historic? It is the prime standard with most active
contributors etc.
Historical is not synonym of out-dated. Historical means it is the first
interpreter, that's all.
We should just call it cphp or something to distinguish language (PHP) from the
php.net reference implementation :)
"Ivan Enderlin @ Hoa" ivan.enderlin@hoa-project.net schrieb:
* the historical interpreter [1],How is that historic? It is the prime standard with most active
contributors etc.
Historical is not synonym of out-dated. Historical means it is the first
interpreter, that's all.
We should just call it cphp or something to distinguish language (PHP) from the
php.net reference implementation :)
What about php-src?
--
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/
"Ivan Enderlin @ Hoa" ivan.enderlin@hoa-project.net schrieb:
"Ivan Enderlin @ Hoa" ivan.enderlin@hoa-project.net schrieb:
* the historical interpreter [1],How is that historic? It is the prime standard with most active
contributors etc.
Historical is not synonym of out-dated. Historical means it is the first
interpreter, that's all.
We should just call it cphp or something to distinguish language (PHP) from the
php.net reference implementation :)
What about php-src?
I am not sure about php-src as it refers to the source itself, but it's fine
by me as long as we have a distinguished name.
"Ivan Enderlin @ Hoa" ivan.enderlin@hoa-project.net schrieb:
"Ivan Enderlin @ Hoa" ivan.enderlin@hoa-project.net schrieb:
* the historical interpreter [1],How is that historic? It is the prime standard with most active
contributors etc.
Historical is not synonym of out-dated. Historical means it is the first
interpreter, that's all.
We should just call it cphp or something to distinguish language (PHP) from the
php.net reference implementation :)
What about php-src?
I am not sure about php-src as it refers to the source itself, but it's fine
by me as long as we have a distinguished name.
Yup, definitively. We will discusss about it later.
--
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/
Hello everyone!
Took some time to read the discussion first before writing anything, so,
here are some thoughts from the userland developer :)
The idea of PHP Spec probably is floating around for a long time and for
good reasons. As we approach the time, when PHP.next becomes a reality, it
is a good time to do it.
I also think it is a good idea to revise if some rarely used PHP features,
that are not implemented in alternate implementations at all, are worth
keeping. Sure, this will not go unnoticed, but pros and cons. Some of it is
not implemented in alternate engines due to performance or is just not
worth it. So, an evaluation is in order I believe.
The second good thing that can come out of it is reevaluation of some type
juggling, clearing up some edge cases and probably finally dealing with the
type hints that generated so much heat and controversy on the list number
of times. On that note, clearing up and tightening up other edge cases is a
good thing.
BUT!
Before everyone gets on the wagon I want to remind everyone that although
PHP Spec is a good thing, there are other more important things to do for
PHP.next. The 64 bit support patch - there is a lot of work converting the
extensions ahead, and this is DAMN IMPORTANT STUFF. Way more important than
PHP Spec. The Unicode problem needs to be worked on too. The Zend Engine
iteration for crying out loud - it's last big update was like what, 10
years ago?
There are also interesting things happening - the Zephyr project, the PHPCC
lib for extension development - these are not just standalone alternate PHP
engines, these projects are directly tied with the original PHP, the one we
are talking about. Establishing a dialog and collaboration can benefit PHP
a lot (I dream of times when most of the PHP extensions could be written
with Zephyr without touching the low-level C - certainly would make
contributions much easier for many of us). Alternate PHP engines can
provide ideas and insights into updating the Zend Engine.
Just my 0.02$ as a userland developer, for whom the future of PHP is
important :)
Arvids.
I want to correct a specific paragraph in my previous email, because I
messed up the wording and that can offend some of the developers. I'm sorry
for this, correcting my mistake.
2014-03-28 12:34 GMT+02:00 Arvids Godjuks arvids.godjuks@gmail.com:
Hello everyone!
....
The Zend Engine iteration for crying out loud - it's last big update was
like what, 10 years ago?
.....
Arvids.
Yeah, when you are not a native speaker and watching too much hollywood
movies.
So, what I meant is that Zend Engine was unable to get major updates, that
will break BC that cannot be broken under the rules of PHP development. And
we all know there is a list of those made. My personal one is the 64 bit
changes, but also the performance related changes and the general
improvement.
Hope I corrected my mistake, everyone have a good Friday!
Arvids.
Hello everyone!
Hello Arvids :-),
[snip]
BUT!
Before everyone gets on the wagon I want to remind everyone that although
PHP Spec is a good thing, there are other more important things to do for
PHP.next.
Sure there is also important features. The PHP Specification would be a
side project with other people. I will try to lead this project on my
own free time. Time which is not dedicated to PHP, so this will change
nothing normally.
--
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/
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.
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.
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.
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’t 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’s 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/
Hello Andrea,
My answer in the mail.
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.
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.
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.
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’t 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.
I am not sure with the last point. A specification is not a
documentation. It explains the syntax and the semantics of the language,
whereas the documentation (as currently written) explains the usage, API
and gives examples. But, a specification could perfectly complete a
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.
Yep, sure! For the first version of the specification, it must match the
prime PHP implementation, aka php-src (I avoid to say “historical
implementation” ;-)). And then, the RFC will apply on the specification
and/or the implementation.
PHP’s 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.
We can target to write the PHP specification along with PHP6
implementation. The specification will reflect the PHP6 implementation.
And the specification will highlight what is messy in the
implementation, and what is not. Consequently, it will provide new clear
goals for future PHP implementations.
--
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/
Hi Guys,
I agree, I think PHP needs a specification. For one thing, a reference implementation is no real specification. It can't be easily consulted, and it also means that any reference implementation bug might be considered a language feature [...]
There are so many bugs which are actually considered features by so
many people of this list. But actually, I'd really love you guys
specify the tons of examples of really weird behaviour found here:
That should be a good read for everyone who thinks that PHP is just
fine and does not need a fundamental redesign.
Just my two cents,
Nils
There are so many bugs which are actually considered features by so
many people of this list. But actually, I'd really love you guys
specify the tons of examples of really weird behaviour found here:
That should be a good read for everyone who thinks that PHP is just
fine and does not need a fundamental redesign.
You seem to contradict yourself here. Do you want those
implementations reverse-engineered into a specification ("spec to
build," as was done with ECMAScript) or do you want a "fundamental
redesign" (implying those examples should behave differently)?
Also, if you submit a list of legit surprises, it shouldn't have
Newbie Nodocs examples cluttering it up. FALSE fails an array
typehint? A string constant can't be checked with instanceof, but a
$variable variant can be? NULL isn't considered scalar? Sorry, these
just don't carry any shock value. Yohgaki's inconsistencies RFC has
much better zingers if that's what you want.
-- Sandy
Hi!
There are so many bugs which are actually considered features by so
many people of this list. But actually, I'd really love you guys
specify the tons of examples of really weird behaviour found here:
In other words, there are a lot of behaviors that you don't like but
many other people on the list and in the community like just fine. This
is normal, people always have different opinions about things, that
doesn't mean there's something fundamentally wrong with each specific
ones. There are tons of blogs where people vent their various
frustrations on life not being perfect and people being annoying by
having different opinions than they do. This is normal too, nothing
fundamentally wrong with that.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Nils Andre wrote:
That should be a good read for everyone who thinks that PHP is just
fine and does not need a fundamental redesign.
This used to be a useful site on how not do do some things, but it needs some
serious cleaning up if only to remove the spam :(
How much of the information actually applies against 5.5 today?
If it was better maintained then it could be a useful reference to PHP6 fixes,
but somehow I think it needs as much work as a PHP Specification ;)
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
We see more and more PHP interpreters or compilers out there:
- the historical interpreter [1],
- interpreter from Facebook [2],
- interpreter written for .NET [3],
- interpreter written for JVM [4],
- maybe I forgot some of them.
HippyVM has been pre-released today [5]. Perfect timing for this thread ;-).
[1] http://php.net/
[2] http://hhvm.com/
[3] https://github.com/DEVSENSE/Phalanger
[4] https://github.com/dim-s/jphp
[5] http://hippyvm.com/blog#introducing-hippyvm
--
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/
On Mon, Mar 24, 2014 at 5:13 PM, Ivan Enderlin @ Hoa
ivan.enderlin@hoa-project.net wrote:
We see more and more PHP interpreters or compilers out there:
- the historical interpreter [1],
- interpreter from Facebook [2],
- interpreter written for .NET [3],
- interpreter written for JVM [4],
- maybe I forgot some of them.
HippyVM has been pre-released today [5]. Perfect timing for this thread ;-).
[1] http://php.net/
[2] http://hhvm.com/
[3] https://github.com/DEVSENSE/Phalanger
[4] https://github.com/dim-s/jphp
Interesting :)
While it is surely much faster than stock php, I am not sure their
benchmark against hhvm is correct, especially as they do not have a
web module ready, meaning that benchs are ran only once. hhvm uses a
profiler and JIT only comes into the game later in the php lifetime,
many requests may be necessary to get full optimization.
One bad point is that they are very likely go half open and
proprietary, I do not see a business coming out of that but a little
niche. Maybe that'll be enough for their needs.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Interesting :)
While it is surely much faster than stock php, I am not sure their
benchmark against hhvm is correct, especially as they do not have a
web module ready, meaning that benchs are ran only once. hhvm uses a
profiler and JIT only comes into the game later in the php lifetime,
many requests may be necessary to get full optimization.One bad point is that they are very likely go half open and
proprietary, I do not see a business coming out of that but a little
niche. Maybe that'll be enough for their needs.
Not that they are alone in the commercial field:
https://github.com/symisc/PH7
btw. a relevant question is whether they actually want to be 100%
compatible, for many purposes a close approximation of the language is
enough. ("simple scripting language for embedding somewhere which people
may learn quickly")
johannes
Wouldn't it make sense to have something like PHP-FIG, but focused on
creating a language specification on top of the current reference
implementation?
On Mon, Mar 24, 2014 at 3:57 PM, Johannes Schlüter
johannes@schlueters.dewrote:
Interesting :)
While it is surely much faster than stock php, I am not sure their
benchmark against hhvm is correct, especially as they do not have a
web module ready, meaning that benchs are ran only once. hhvm uses a
profiler and JIT only comes into the game later in the php lifetime,
many requests may be necessary to get full optimization.One bad point is that they are very likely go half open and
proprietary, I do not see a business coming out of that but a little
niche. Maybe that'll be enough for their needs.Not that they are alone in the commercial field:
https://github.com/symisc/PH7btw. a relevant question is whether they actually want to be 100%
compatible, for many purposes a close approximation of the language is
enough. ("simple scripting language for embedding somewhere which people
may learn quickly")johannes
--
--
Klaus Silveira
(011) 8564-2492
www.klaussilveira.com
Wouldn't it make sense to have something like PHP-FIG, but focused on
creating a language specification on top of the current reference
implementation?
Creating a new group or not is just a marketing buzzy question from my
point of view. People who knows PHP are here on internal@. However, the
processus will be opened to everyone, especially to “implementors”.
--
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/
Hello :-),
We see more and more PHP interpreters or compilers out there:
- the historical interpreter [1],
- interpreter from Facebook [2],
- interpreter written for .NET [3],
- interpreter written for JVM [4],
- maybe I forgot some of them.
Google App Engine's PHP Interpreter has a few modifications from the
core standard. At least one that I know of is that the mail() function
is replaced with a dummy function which does not send anything[since
your not allowed to make outgoing socket connections].
Deploying an app on GAE, as well as digging into HHVM was the reason for
my proposal to add functionality so that the mail() function can be
handled as elegantly as opening a stream or storing session data.
Rather then having to code in ugly checks for what php platform your
using and what PHP platform your using, it is much simpler to just use
the mail() function and leave it up to PHP to allow different types of
delivery based on what mail handler is currently active.
Beyond that, I agree that it would be good to generate specs for the
system in a better manner. One thing I ran into when trying out HHVM a
while back was that it could not handle some non-documented 'features'
For example, under PHP it is[or at least was under 5.4] possible to pass
a private method for a class to spl_autoload_register. Since the
manual specifies that the method passed must be public, that is how HHVM
was initially designed - it matched the public spec.
Registering a private method for spl_autoload_register will cause weird
and difficult to debug errors is the private method throws an exception.
So that would be a good item to decide on precisely what functions and
methods can be registered as an autoloader - if private ones should be
allowed, then the exception handling has to be fixed. If they should
not be allowed, then at some point this "feature" should be removed from
the PHP interpreter.
Hello :-),
We see more and more PHP interpreters or compilers out there:
- the historical interpreter [1],
- interpreter from Facebook [2],
- interpreter written for .NET [3],
- interpreter written for JVM [4],
- maybe I forgot some of them.
Google App Engine's PHP Interpreter has a few modifications from the
core standard. At least one that I know of is that themail()
function is replaced with a dummy function which does not send
anything[since your not allowed to make outgoing socket connections].Deploying an app on GAE, as well as digging into HHVM was the reason
for my proposal to add functionality so that themail()function can
be handled as elegantly as opening a stream or storing session data.Rather then having to code in ugly checks for what php platform your
using and what PHP platform your using, it is much simpler to just use
themail()function and leave it up to PHP to allow different types of
delivery based on what mail handler is currently active.Beyond that, I agree that it would be good to generate specs for the
system in a better manner. One thing I ran into when trying out HHVM
a while back was that it could not handle some non-documented
'features' For example, under PHP it is[or at least was under 5.4]
possible to pass a private method for a class to
spl_autoload_register. Since the manual specifies that the method
passed must be public, that is how HHVM was initially designed - it
matched the public spec.Registering a private method for spl_autoload_register will cause
weird and difficult to debug errors is the private method throws an
exception. So that would be a good item to decide on precisely what
functions and methods can be registered as an autoloader - if private
ones should be allowed, then the exception handling has to be fixed.
If they should not be allowed, then at some point this "feature"
should be removed from the PHP interpreter.
This is exactly those kinds of things that must be specified. And I am
even not sure that PHP is consistent with this ;-).
--
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/
[...]
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.
Hi,
I just did a quick skim of some of the specs you linked, this is what
came out:
- ECMAScript - 258 pages
- C99 - 552 pages
- Java - 780 pages
- Ocaml - No PDF, but it looks digestible (syntax only)
Sooo, while I wouldn't object to a spec per se, I don't think a simple
"hey we need this" is in any way feasible.
Where would you even start? Syntax? Make sense of PHP's parser grammar?
If you look at the state of the wiki, the amount of verifiable up to
date technical documentation is in a quite sorry state (when you think
about a history of ~20 years) - that is not to say I don't approve of
the recent efforts to fix this problem.
Another point is that PHP is evolving faster than ever in the past,
release cycles are actually quite short - how can you "freeze" stuff and
even begin to commit to a timeframe of even a few months to write down
this spec. Then who decides what is working as intended and what is a bug?
So yes, I don't think there'd be a lot of objection if someone magically
delivered parts of a language spec that is accurate to the current
release (let's say 5.6 for now) - but who will do it? PHP's design has
always been "fix your own itch, commit it, and as long as it doesn't
interfer too much, it's good"
Cheers,
Florian
Another point is that PHP is evolving faster than ever in the past,
release cycles are actually quite short - how can you "freeze" stuff and
even begin to commit to a timeframe of even a few months to write down
this spec. Then who decides what is working as intended and what is a bug?So yes, I don't think there'd be a lot of objection if someone magically
delivered parts of a language spec that is accurate to the current
release (let's say 5.6 for now) - but who will do it? PHP's design has
always been "fix your own itch, commit it, and as long as it doesn't
interfer too much, it's good”
PHP 6 is a good opportunity. We’ll have more than the usual year to work on it.
--
Andrea Faulds
http://ajf.me/
[...]
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.
Hi,
I just did a quick skim of some of the specs you linked, this is what
came out:
- ECMAScript - 258 pages
- C99 - 552 pages
- Java - 780 pages
- Ocaml - No PDF, but it looks digestible (syntax only)
Sooo, while I wouldn't object to a spec per se, I don't think a simple
"hey we need this" is in any way feasible.Where would you even start? Syntax? Make sense of PHP's parser grammar?
Please, read the email I sent today at 9.31am (GMT+1) [1].
If you look at the state of the wiki, the amount of verifiable up to
date technical documentation is in a quite sorry state (when you think
about a history of ~20 years) - that is not to say I don't approve of
the recent efforts to fix this problem.Another point is that PHP is evolving faster than ever in the past,
release cycles are actually quite short - how can you "freeze" stuff and
even begin to commit to a timeframe of even a few months to write down
this spec. Then who decides what is working as intended and what is a bug?
I think we have to learn from the past and experiences of other
projects. Maybe the best way to write such a specification is to adopt
the approach of the CSS Working Group [2] where they have split the
specification into modules [3, 4].
So yes, I don't think there'd be a lot of objection if someone magically
delivered parts of a language spec that is accurate to the current
release (let's say 5.6 for now) - but who will do it? PHP's design has
always been "fix your own itch, commit it, and as long as it doesn't
interfer too much, it's good"
Well. It could be that it was the wrong design ;-) ?
I don't think it will be difficult. php-src will continue to leave as it
is until we have the first specification draft delivered, and then, for
each written and validated specification parts/modules, php-src will
adapt its behavior, step by step. It will not be an earthquake…
Regards.
[1] http://news.php.net/php.internals/73414
[2] http://www.w3.org/Style/CSS/
[3] http://www.w3.org/Style/CSS/current-work
[4] http://www.w3.org/standards/techs/css
--
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/
Hi!
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.
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 of
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?
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.
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.
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
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.
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
Thoughts?
If you're ready to start such project, go ahead and do it. I personally
wish you all the luck.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi Stas :-),
Hi!
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.
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 of
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
implementations. Something like a subset of the php-src which includes
the syntax, the semantics, the tool and the standard library (ext/core,
ext/standard, ext/stream, ext/spl and some others). Maybe the standard
library of php-src could also be “refactored” (I prefer
“re-architectured”) in order to be clearer what is standard and what is
not from the user point of view. However, such points will be clarified
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
“abstract” (understand implementation-free) tests suite. This is how the
majority of projects work. And this will be complementary of the
php-src, HHVM etc. test suites (but it would have to be exhaustive, and
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
does not sound too pejorative, my mistake! Johannes used the term “prime
implementation” which is good also, but “official” sounds good enough
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 interpreter
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
be. For Web technologies, this is exactly the same thing. We have
standards/specifications, and implementations. One vendor proposes a new
features through an implementation and a specification proposal. It is
discussed at the specification level and then valided or not. If it is
validateed, then other vendors will update their implementation to
respect the specification. If it is not validated, then either they
review their proposal or they give up or at last they keep it as
“private”. And this last option is not bad at all: if they need this
feature, well, they implement it and that's good. If a user would like
such a feature, then it will use this implementation. But if someone is
making a framework, a set of libraries, a big tool, that is intented to
be used by every PHP user, then, it will develop in regards of the
standard/specification. That's how things work. And if a feature in a
specification implementation appears to be very attractive for users,
then the “specification consortium” could revise its position. This is a
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 to
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.
Things are clear in my head, maybe I could draft something in few weeks.
Regards.
[1] http://news.php.net/php.internals/73417
--
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/
Hello :-),
We see more and more PHP interpreters or compilers out there:
- the historical interpreter [1],
- interpreter from Facebook [2],
- interpreter written for .NET [3],
- interpreter written for JVM [4],
- maybe I forgot some of them.
Google App Engine's PHP Interpreter has a few modifications from the
core standard. At least one that I know of is that the mail() function
is replaced with a dummy function which does not send anything[since
your not allowed to make outgoing socket connections].
Deploying an app on GAE, as well as digging into HHVM was the reason for
my proposal to add functionality so that the mail() function can be
handled as elegantly as opening a stream or storing session data.
Rather then having to code in ugly checks for what php platform your
using and what PHP platform your using, it is much simpler to just use
the mail() function and leave it up to PHP to allow different types of
delivery based on what mail handler is currently active.
Beyond that, I agree that it would be good to generate specs for the
system in a better manner. One thing I ran into when trying out HHVM a
while back was that it could not handle some non-documented 'features'
For example, under PHP it is[or at least was under 5.4] possible to pass
a private method for a class to spl_autoload_register. Since the
manual specifies that the method passed must be public, that is how HHVM
was initially designed - it matched the public spec.
Registering a private method for spl_autoload_register will cause weird
and difficult to debug errors is the private method throws an exception.
So that would be a good item to decide on precisely what functions and
methods can be registered as an autoloader - if private ones should be
allowed, then the exception handling has to be fixed. If they should
not be allowed, then at some point this "feature" should be removed from
the PHP interpreter.
My advice:
This needs to happen in structured, organized steps with each step focusing
a major system or subsystem. A few examples of systems or subsystems:
- Language Syntax (please use a formally defined grammar!)
- Error levels
- Primitive types
- Array Model
- Object Model
- PHP Test model
I'd propose that initially the specifications do not alter from the current
de facto Zend standard. I'd also add the phpt tests with a way to run them
to ease compliance with new implementations.
Once everything is clearly outlined (which is a lot of work) the hard
work begins: getting all the implementation vendors to talk about a new
draft to overcome current Zend challenges.