Re: Introducing "Array Of" RFC
| From: | Joe Watkins | Date: | Mon, 20 Jan 2014 09:33:37 +0000 |
| Subject: | Re: Introducing "Array Of" RFC | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-71314@lists.php.net to get a copy of this message | ||
On 01/20/2014 04:19 AM, Rasmus Lerdorf wrote:
On 1/19/14, 9:13 AM, Philip Sturgeon wrote:On 01/20/2014 04:19 AM, Rasmus Lerdorf wrote:> I do have an issue with the idea that the rightI think its a nice logical improvement which syntactically offers a replacement for looney boilerplate code, exactly like Variadics which a LOT of people are excited about.Actually variadics solves a problem that can't be solved other ways, namely by-ref for an unknown number of arguments. There is no userspace boilerplate code, looney or otherwise, that can do that. I won't argue whether the base need is great enough here. I am sure it is to some people. I do have an issue with the idea that the right solution is a full hash table scan on every function call. I have a feeling that if this makes it in this is one of those features that will be high my list for optimization/refactoring when I run across it in code. As in, replace the per-call hash scan with a single userspace scan that is only done once earlier in the stack. From a performance perspective the only-done-once userspace version is extremely likely to outperform this built-in per-call check assuming more than a trivial amount of calls to the function in question. -Rasmus
solution is a full hash table scan on every function call.Rasmus, The better solution here appears (to everyone else) to be generics, which you actually said you didn't want to see anywhere near PHP, please could you communicate your reasons for that ? I have concerns ... I'm concerned that type hinting isn't robust or complete enough to compliment using generics. I'm wary of the inherent complexity that generics carries both in it's implementation and usage. I'm concerned that we already have many different kinds of collection, and they have introduced inconsistencies (Traversable != array), I don't really see a way to add another, and such a complex one, without introducing more, or alternatively impacting everything. It's a bit crazy to implement a whole paradigm because we wanted a specific kind of type hint. Is it any of them ?? Is it something I, or any of the others thinking about generics, don't see ?? Do you, or anyone else, anyone at all, see a way to perform the simple type hint we set out to perform without incurring the overhead of a full table scan ? I don't want to set out to do anything that is bad, however, I think the performance thing is not really a massive concern, after all it's not very difficult for something innocent to incur a measurable overhead: https://eval.in/91920 And we're not all going around re-factoring our code to avoid that, because it's "normal"; people know that passing a huge array around increases memory usage because it's documented, so I don't see the problem with documenting how this would work such that those that need to avoid the overhead, can. Also, variadics incur the same overhead: http://lxr.php.net/xref/PHP_5_6/Zend/zend_vm_def.h#3448 The idea to change the hashtable wouldn't work anyway (for the OP of the idea): you can have a reference to a variable that is a member of an array and change it's type without executing any opcodes related to hashtable manipulation. Cheers Joe