Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71310
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <52DCD8B5.6060006@lerdorf.com>
References: <CABDNdAGCH5i9-=4Ys1CXeNaGWGmX=mkTiq0b7BbUKtBPdQ9XVg@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>
	<52DCC067.9090603@garfieldtech.com>
	<CAJ26g5T9R8U4dJrmr1E-XZCe=RH65QQCEt7F5dQ1MfsR+LbSZQ@mail.gmail.com>
	<52DCD8B5.6060006@lerdorf.com>
Date: Mon, 20 Jan 2014 09:46:49 +0100
Message-ID: <CAEZPtU7+VhGvoPcX3GEssKVcKG6fBZCcatWDnTva3c-U93bzXw@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Patrick Schaaf <bof@bof.de>, Larry Garfield <larry@garfieldtech.com>, 
	internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Introducing "Array Of" RFC
From: pierre.php@gmail.com (Pierre Joye)

hi,

On Mon, Jan 20, 2014 at 9:05 AM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
> On 1/19/14, 11:31 PM, Patrick Schaaf wrote:
>> Regarding the N*M checking complexity, couldn't a little bit of memory
>> alleviate the problem?
>>
>> For each array, have a "member type" pointer, initially NULL.
>>
>> When the member type needs to be checked for the first time, and that
>> "member type" pointer is not already set, do an O(N) scan of the arrray,
>> testing compatibility of all members against the hinted type. Error on
>> mismatch, but when all members match, remember the type behind the "member
>> type" pointer.
>>
>> When the member type needs to be checked and the "member type" pointer _is_
>> set, just compare it to the hinted type O(1).
>>
>> There must be some overhead when elements are added to an array. Either
>> "when member type is set, forget it", or even "when member type is already
>> set, check compatiility of the newly added element with the member type,
>> and then remove member type on mismatch or keep it on match".
>
> This means every HT becomes larger now and every time you write to a HT
> you at the very least need to do one extra comparison. We use HTs
> everywhere, so this would have a performance impact on every script even
> if you have absolutely no intention of ever using this feature.

As I like this RFC for other reasons (type hinting extension), I tend
to think that the use cases presented here can be done in a more
efficient way. Someone else mentioned "collections" and it is exactly
what it is all about. A collection could be an instance of a given
class, which stores only one class type. It prevents on usage/function
call checks and checks are done only when adding a member to the
collection.

On another note, and only as a note here as I really do not want to
hijack this thread with another topic, the more I see this kind of
RFCs the more I feel like we are heading to general or global  type
hinting supports. I think it could be the right time to actually
decide what we want. It is getting critical as we keep adding stuff
about type hinting, one after another, which may lead to
inconsistencies and will prevent us to have a good type hinting
mechanism in PHP.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org