Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73395
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.115 as permitted sender)
Message-ID: <5330B375.5030704@sugarcrm.com>
Date: Mon, 24 Mar 2014 15:36:37 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "Ivan Enderlin @ Hoa" <ivan.enderlin@hoa-project.net>, 
 'internals' <internals@lists.php.net>
References: <532FF7B9.5040700@hoa-project.net>
In-Reply-To: <532FF7B9.5040700@hoa-project.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] PHP Specification
From: smalyshev@sugarcrm.com (Stas Malyshev)

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