Hi Nikita, > On Jan 18, 2020, at 5:05 AM, Nikita Popov <nikita....@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' => 10240]. Append a string value to the array and then the types would be ['int' => 10240, 'string' => 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. 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 — as I am not (yet) a PHP internals developer — and not just assuming they are viable options. -Mike [1] https://nikic.github.io/2012/03/28/Understanding-PHPs-internal-array-implementation.html 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
