Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:71323 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 60332 invoked from network); 20 Jan 2014 12:08:52 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Jan 2014 12:08:52 -0000 Authentication-Results: pb1.pair.com header.from=inefedor@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=inefedor@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.46 as permitted sender) X-PHP-List-Original-Sender: inefedor@gmail.com X-Host-Fingerprint: 209.85.215.46 mail-la0-f46.google.com Received: from [209.85.215.46] ([209.85.215.46:55496] helo=mail-la0-f46.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id AA/8B-02192-4D11DD25 for ; Mon, 20 Jan 2014 07:08:52 -0500 Received: by mail-la0-f46.google.com with SMTP id b8so5450271lan.19 for ; Mon, 20 Jan 2014 04:08:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:to:subject:references:date:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; bh=Q+FinwWk6NL8VmeNtTpetyslio4IHTbQkXm17OViQvE=; b=xs8Tj7kzeLLOPJz00FBLlE1AuCsljMTiJkwp2aazUg0GMVBtDRNz2r/djc4iHNcgqL 5B96uL3h2VWRBiw+u42MVD2YaWM1T0ca4A3XRajh/WzR67RuSX5GU7NalczOwAccnDhA nvF42xnA5RKYSh4TB6hp/QqRjobsktjT7KupbhGuQsLf6dNVilVi+B3ABtGr1HD3owXY s9lkbR+rBFEP4l4SpsrGQ2L/L81oJBagssHclMf7sfJhJ3Z5SaudTnBKYSv4QuJ/faB/ C1IkC/3BsNZXfqftRPpVfMIdWv3j54J4jh5Gj4lVo99PE6tMH3/gM8RX8mMbMUixWNya xZ/Q== X-Received: by 10.112.146.233 with SMTP id tf9mr11204693lbb.28.1390219729310; Mon, 20 Jan 2014 04:08:49 -0800 (PST) Received: from nikita2206-n56vj ([217.174.184.92]) by mx.google.com with ESMTPSA id np10sm659535lbb.7.2014.01.20.04.08.48 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 20 Jan 2014 04:08:48 -0800 (PST) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: internals@lists.php.net References: <002d01cf1234$01e6dc60$05b49520$@tutteli.ch> <004c01cf123d$35730870$a0591950$@tutteli.ch> <52D71748.1090402@googlemail.com> <52D71FAE.8030002@ajf.me> <005001cf124f$3a40df00$aec29d00$@tutteli.ch> <20140116110127.202079vzjsj76n7b@webmail.tutteli.ch> <0B.B1.24763.139B7D25@pb1.pair.com> <002001cf12da$2bfbda90$83f38fb0$@tutteli.ch> <52DCA3E7.80602@lerdorf.com> <52DCC067.9090603@garfieldtech.com> Date: Mon, 20 Jan 2014 16:08:47 +0400 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: User-Agent: Opera Mail/12.16 (Linux) Subject: Re: [PHP-DEV] Introducing "Array Of" RFC From: inefedor@gmail.com ("Nikita Nefedov") On Mon, 20 Jan 2014 11:31:17 +0400, 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". > > Finally when arrays are copied, and "member type" is already set, copy it > along with the array, Optionally some of the array functions like > array_merge might be made aware of the scheme, too. > > BTW, I'm undecided regarding the need for the overall feature, from my > rather limited personal coding practise it seems to me that whenever I am > interested in member type checking I'm already looping over the array and > can easily add up-front instanceof checks to the loops with suitable > explicit error-out. Which I generally prefer over automatic errors, > especially fatal ones, because _I_ control the error case behaviour. > > But I think _if_ such a scheme were added, the implementation described > above would solve the O(N*M) problem with acceptable overall cost. > > best regards > Patrick Hi Patrick, I had this cache-idea too, but it will fail to get you any speedup if you check for array of interfaces (if you want to store objects of different classes but all this classes implement one interface). And this is the same reason why this proposal is very different from having typed array structure (cause, as long as I know, type of the typed array is always the end-class, objects of which will be stored in this array). So if we are proposing to add some new Spl structure - keep that in mind. And again, reference to an element in the array can be used to change element of the array without affecting (and thus calling any of the functions related to) HT.