Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108200
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <CAF+90c8yAqHeLRzeX0sYxnQ30JAtg=Ubp7sDyonCkS5V7goN5A@mail.gmail.com>
Date: Sun, 19 Jan 2020 19:53:10 -0500
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <5DC86728-1BBF-4DCA-8A6B-9B0B190DB99D@newclarity.net>
References: <CAKtGGAsh-38W1UjgDaoQFzhKNOqTy3QGV8fE1-6-PPob2zw6Vw@mail.gmail.com>
 <CAF+90c8yAqHeLRzeX0sYxnQ30JAtg=Ubp7sDyonCkS5V7goN5A@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Subject: Re: [PHP-DEV] Typed array properties V2
From: mike@newclarity.net (Mike Schinkel)

Hi Nikita,

> On Jan 18, 2020, at 5:05 AM, Nikita Popov <nikita.ppv@gmail.com> =
wrote:
> Did you read through the previous discussions on this topic?
> https://externals.io/message/100946 in particular comes to mind.

Thanks for this link. It was very insightful.

> The primary concern about the previous typed array proposal was the =
O(n)
> cost of type checks, which required iterating over the whole array and
> checking the type of individual elements. Any new proposal in this =
area
> *must* address this concern.

Agreed.

> As far as I know, the only viable way to do that is to make the array
> intrinsically typed, which means that types are validated when =
elements are
> inserted into the array, not when it is passed across a function =
boundary.
> In other words, array generics.

Reading the prior discussion, there appeared to be several other =
potential approaches, but none were followed to a conclusion.  Of course =
it devolved into bikeshedding, but I digress...

One approach mentioned by Andrea Faulds was to extend the hashtable =
(ref: your article[1]) and count types as assigned just like we =
currently count references.  So a 10,240 element array of ints could =
have an internal tracker showing that the array contains type(s): ['int' =
=3D> 10240].   Append a string value to the array and then the types =
would be ['int' =3D> 10240, 'string' =3D> 1].

Mark Randall mentioned that this would not work if the array contained =
references, but no one discussed the potential of simply disallowing =
arrays with references at compile time when the arrays are typehinted, =
which seems like it could solve the proverbial 80/20 scenario.  Need =
references in arrays?  Don't typehint them.

Also, Rowan Collins mentioned that checks in Go can be disabled for =
runtime checking; maybe we could support an option that disables said =
checking so that production sites could run w/o checks but we could run =
checks in development, testing and staging. We could also have an option =
to disable checking of array types above a given size of array, maybe =
defaulting to 1024? Clearly both of these would be no worse than what we =
have today.=20

I think this could add a major improvement to PHP all without having to =
finalize the design and implementation of generics, no?

Are none of these viable options?  I am asking that as a legitimate =
question =E2=80=94 as I am not (yet) a PHP internals developer =E2=80=94 =
and not just assuming they are viable options.

-Mike

[1] =
https://nikic.github.io/2012/03/28/Understanding-PHPs-internal-array-imple=
mentation.html=20

P.S.  There was also the mention by Levi Morrison that the type[] syntax =
was a poor one because of ambiguity between (?int)[] or ?(int[]).  I =
would argue that the latter would likely occur orders of magnitude more =
often than the former, so I would argue that ?int[] should interpret as =
?(int[]), and if they want (?int)[] then the developer should use =
parentheses.