Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101587
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain lerdorf.com designates 74.125.82.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAHWSxWQHtPZdnfA5P4da4ETpQzFTGB_sKDT73vtM15tbNjYi_A@mail.gmail.com>
References: <CAEUnE0d+rHG-Rvjt7QAN6x6L+BP5Yb_cz8sGuOFDOkx-kCehkA@mail.gmail.com>
 <9a3a8760-f65a-a5c0-b318-1830a9a986c3@gmail.com> <CAH0Uv3H_DEPZ5HmaKGe08_DMrzndBz7ofJTUgeb4f66zeaj1EA@mail.gmail.com>
 <9352F6DF-9940-49A2-9B1D-FA9258E9738E@lerdorf.com> <bb4579ba-2e09-4199-a871-be4428a1ee2d@lsces.co.uk>
 <ee3d2ffc-a72c-78f3-281b-dd029c706105@gmail.com> <CAEUnE0eShfm4kZck=2gBef6cgU6DdrKggtotUK+Jyk6uPYOYFg@mail.gmail.com>
 <CACXBjugZrXXORVsaFhJzRO_WEiUXnVEHBBuHZysPUGRN6Ls7nw@mail.gmail.com>
 <CAEUnE0ce2HRfsKOy_=NSnrENUnGpB4m-C=cMQFV93MgbaMguOQ@mail.gmail.com> <CAHWSxWQHtPZdnfA5P4da4ETpQzFTGB_sKDT73vtM15tbNjYi_A@mail.gmail.com>
Date: Wed, 10 Jan 2018 10:27:57 -0800
Message-ID: <CACXBjuibgJfRCvp6rpuqZj8BoF9Cdwhmu4oxxqw908NZy4h49w@mail.gmail.com>
To: Ryan Jentzsch <ryan.jentzsch@gmail.com>
Cc: Michael Morris <tendoaki@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="001a11c0ab9031d9b705627033be"
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax
From: rasmus@lerdorf.com (Rasmus Lerdorf)

--001a11c0ab9031d9b705627033be
Content-Type: text/plain; charset="UTF-8"

On Wed, Jan 10, 2018 at 10:11 AM, Ryan Jentzsch <ryan.jentzsch@gmail.com>
wrote:

> I agree with Michael (to a large degree) and I think I see clearly
> Michael's point:
> Under the current system I will NEVER create an RFC (or find someone with
> the Zend engine coding chops to help me) because the RISK vs. REWARD with
> the current RFC system is too likely to be a colossal waste of everyone's
> time.
> Currently the tail wags the dog (implementation details govern top level
> policy). The current process nearly insists I spend valuable time coding up
> front with a good chance that if/when the RFC goes up for a vote someone
> will still be bleating about syntax, or using tabs vs. spaces, or some
> other minor detail -- with a 2/3 vote needed it may shoot all my
> preliminary hard work to hell. No thanks.


There is a middle ground here. I agree that doing months of work on a
rock-solid implementation doesn't make sense if you don't know the RFC will
pass. On the other end of the spectrum, RFCs that are essentially feature
requests with no specifics on the actual implementation also don't make any
sense. A good RFC strikes a happy balance between the two. For many/most
things, the actual work in figuring out the implementation isn't that bad.
As Sara said, a full implementation isn't needed, but a rough sketch of
what changes are needed along with their potential impact on the existing
code definitely is. And yes, unfortunately, if your RFC touches the basic
building block of PHP, the zval, then that rough sketch becomes even more
important. If you stay away from trying to change a 25-year old loosely
typed language into a strictly typed one, then the RFC becomes much simpler.

-Rasmus

--001a11c0ab9031d9b705627033be--