Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73430
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <532FF7B9.5040700@hoa-project.net>
References: <532FF7B9.5040700@hoa-project.net>
Date: Tue, 25 Mar 2014 14:11:03 -0600
Message-ID: <CAFMT4Nqv1j0LgVG7S0ubR+RMmNWG+VdaH+5FBK84h=aeFJBr1g@mail.gmail.com>
To: "Ivan Enderlin @ Hoa" <ivan.enderlin@hoa-project.net>
Cc: internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0112c4bc96ad9004f573f328
Subject: Re: [PHP-DEV] PHP Specification
From: morrison.levi@gmail.com (Levi Morrison)

--089e0112c4bc96ad9004f573f328
Content-Type: text/plain; charset=ISO-8859-1

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.

--089e0112c4bc96ad9004f573f328--