Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101550
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain dqxtech.net from 209.85.215.46 cause and error)
MIME-Version: 1.0
In-Reply-To: <CA+kxMuRWZg368sscwd_NTPUUacPcjfB0T_7e4LEwtsEMh2j_dw@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> <CAEUnE0fn8dLWssj-zkQHX_tWr0uw=j4WTQQfKwvb4cb0O0yYxw@mail.gmail.com>
 <CA+kxMuRWZg368sscwd_NTPUUacPcjfB0T_7e4LEwtsEMh2j_dw@mail.gmail.com>
Date: Fri, 5 Jan 2018 15:33:12 +0100
Message-ID: <CAH0Uv3FYt9VzJ8CWAFWd7AJi47FZDSGZB+gwhDhTDzUV2Hr6Xw@mail.gmail.com>
To: Dan Ackroyd <danack@basereality.com>
Cc: Michael Morris <tendoaki@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: andreas@dqxtech.net (Andreas Hennings)

On 5 January 2018 at 11:35, Dan Ackroyd <danack@basereality.com> wrote:
> On 5 January 2018 at 02:01, Michael Morris <tendoaki@gmail.com> wrote:
>>
>> what if the underlying zval wasn=E2=80=99t a zval but a separate
>> class specific to the data type but implementing the same interface as
>> zval?
>
> I believe the only sensible answer to that is 'mu', as that question
> is based on misunderstanding.
>
> The internals of the PHP engine is C, and zvals are structs not
> classes, and so there is no interface. In userland classes are also
> zvals.  http://www.phpinternalsbook.com/php7/internal_types/zvals/basic_s=
tructure.html


I think a good beginners intro is this,
http://php.net/manual/de/internals2.variables.intro.php

Yes, these things are structs, and there are no interfaces.

It would be possible, in theory, to create a different struct for
type-locked variables, where the type is not stored with each
instance, but in the opcode.
Or perhaps separate structs per type.

This would obviously be a huge amount of work, and a radical change to
the language, so I do not imagine this going to happen any time soon.
Every place in code that currently deals with the _zval_struct would
then have to consider all other structs.
The opcode could then be optimized for such type-locked variables, and
this would reduce cost in memory and performance.

The next best thing would be to keep the existing _zval_struct also
for type-locked variables, and still try to optimize the opcode as if
the type is known at compile time.
Still a lot of work, I imagine, because it still affects every place
where we deal with a variable.

The third option is to keep the implementation as if all types are
dynamic, and only add some type checks here and there, which can be
globally enabled or disabled.
This is what other gradually typed languages do, as pointed out by
Rowan Collins,

> The biggest issue with any proposal, though, is going to be performance. =
I don't think this is an incidental detail to be dealt with later, it is a =
fundamental issue with the way type hints in PHP have evolved. PHP is extre=
mely unusual, if not unique, in exclusively enforcing type constraints at r=
untime. Other languages with "gradual typing" such as Python, Hack, and Dar=
t, use the annotations only in separate static analysers and/or when a runt=
ime debug flag is set (similar to enabling assertions).


>
> Also, I think people who try to guess at how to make changes to the
> engine, are doing a small disservice to people who have already tried
> to implement this.

This is a dilemma.
I think there are some people with valuable opinions on language
design, which did not find the time yet to study the engine
implementation.
So, either we risk occasional ignorant ideas, or we will miss some
valuable contributions.

I personally want to eventually study the engine in more detail, but I
don't think I need to completely self-censor myself until then.
Instead, I have to make a judgement call each time if my limited
understanding is sufficient to allow a meaningful contribution to the
discussion.