Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71314
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 74.125.82.44 cause and error)
Message-ID: <52DCED71.3020207@pthreads.org>
Date: Mon, 20 Jan 2014 09:33:37 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: internals@lists.php.net
References: <CABDNdAGCH5i9-=4Ys1CXeNaGWGmX=mkTiq0b7BbUKtBPdQ9XVg@mail.gmail.com>	<002d01cf1234$01e6dc60$05b49520$@tutteli.ch>	<CABDNdAEAQyyLQXFw3tw8S9Rb=+9Z-k1K_geX6HG7x1reCoJ5Rw@mail.gmail.com>	<004c01cf123d$35730870$a0591950$@tutteli.ch>	<52D71748.1090402@googlemail.com>	<52D71FAE.8030002@ajf.me>	<005001cf124f$3a40df00$aec29d00$@tutteli.ch>	<CAEp07h_KDafvOMzxVmgQq1XMeO_N3CWdFCN0vVgdxXtEn6imKg@mail.gmail.com>	<20140116110127.202079vzjsj76n7b@webmail.tutteli.ch>	<0B.B1.24763.139B7D25@pb1.pair.com>	<002001cf12da$2bfbda90$83f38fb0$@tutteli.ch>	<CAMUwpuRLfwru8XT64=j5LsNyG_DkwU_i0oHPHqfmn2HuLt+28A@mail.gmail.com>	<CAGAGxbZcj91m0DgBi8ZMBWw400nem+Xkt6VbFBxSVLYWYEC0VA@mail.gmail.com>	<CAFRKLUNL_4Kyxe3HRs70Xgsiy4pKo0rsEnEyPCT80B7W20U6jQ@mail.gmail.com>	<CAGAGxba2U0_pK0kXx-+N=34UJiLUd9ev-TNf=R+jMzzVRGzW3w@mail.gmail.com>	<CAL+t6cE5KxpfSny3pNyW1s-0v00ocC7g=ee6AKcxo1bYoBrKeg@mail.gmail.com> <CABDNdAG60oWEkjRegE4qc6WE_KcJvv=uqtVPRzihm-42PRcgyg@mail.gmail.com> <52DCA3E7.80602@lerdorf.com>
In-Reply-To: <52DCA3E7.80602@lerdorf.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Introducing "Array Of" RFC
From: pthreads@pthreads.org (Joe Watkins)

On 01/20/2014 04:19 AM, Rasmus Lerdorf wrote:
> On 1/19/14, 9:13 AM, Philip Sturgeon wrote:
>> I 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
>

On 01/20/2014 04:19 AM, Rasmus Lerdorf wrote:> I do have an issue with 
the idea that the right
 > 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