Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101585
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.216.173 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <CAESVnVp=E6nakO+pgb5B0bOsLou91zdY7id=SMnzVk03BzPeUQ@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> <CAESVnVp=E6nakO+pgb5B0bOsLou91zdY7id=SMnzVk03BzPeUQ@mail.gmail.com>
Date: Wed, 10 Jan 2018 12:08:41 -0500
Message-ID: <CAESVnVq5EfR8-jx5NaJeC+TN4wp6shVaPEwL92c_LE2kGMtcdg@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Andreas Hennings <andreas@dqxtech.net>, Rowan Collins <rowan.collins@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax
From: pollita@php.net (Sara Golemon)

On Wed, Jan 10, 2018 at 12:01 PM, Sara Golemon <pollita@php.net> wrote:
> On Thu, Jan 4, 2018 at 8:21 PM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote=
:
>> I think you, and many others, commenting here, should start by looking
>> at the engine implementation. Any successful RFC needs to have a strong
>> implementation behind it, or at the very least a very detailed descripti=
on of
>> how the implementation would mesh with the existing engine code.
>>
>> The reason we don=E2=80=99t have typed properties/variables is that it w=
ould
>> require adding type checks on almost every access to the underlying
>> zval. That is a huge perf hit compared to only doing it on method/functi=
on
>> egress points as we do now.
>>
>
>
**agh-mistabbed into a send

I'm going to underline Rasmus' comment here.  zval assignment is a
deep/core element of what the engine does.  Even when it's not a
literal `$x =3D "foo";` in userspace, zvals are flying around the engine
constantly.  Adding so much as a Z_TYPEINFO_P(val) & ZVAL_FLAG_STRICT
check to EVERY ONE OF THOSE accesses is both heavy-weight and
massively complex.  On the order of the php-ng rewrite complexity,
because EVERY assignment needs to be dealt with, and there WILL be
some misbehaving extension out there which gets it wrong.

The implementation essentials are not a trivial part of such a
feature.  You don't need to have the entire implementation written and
tested, but you do need to have a clear plan for how and what will be
done and vitally, what the impact of that plan will be.  You can't
just waive your hands and say: "We'll sort this out..."

"How does HackLang do this?" has been asked of me offline, so I want
to put my answer here:  IT DOESN'T.

HackLang relies of static analysis to prove "$x will never be assigned
a non-integer, so we can always assume it's an integer".  This is done
by the static analysis tool before the site is ever run, not at
runtime.  Why? Because the HHVM could see the same thing Rasmus is
telling you.  Runtime type enforcement is damned expensive.

-Sara