Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71296
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.25 cause and error)
Message-ID: <52DCC067.9090603@garfieldtech.com>
Date: Mon, 20 Jan 2014 00:21:27 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
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: larry@garfieldtech.com (Larry Garfield)

On 01/19/2014 10:19 PM, 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

Which I think goes to the earlier point about it being better to do at 
add-time than read-time, since add-time is O(n) and read-time is O(n*m).

Stepping back a bit, the underlying feature request, essentially, is "I 
want to ensure I have a collection of X without having to write a custom 
collection class every frickin' time".  (Writing a FooCollection class 
whose add() method only accepts Foo objects is very straightforward, but 
generally needless boilerplate.)  That can be checked at add time or 
read-time.  I think that's an entirely valid use case in modern code, 
and can help lead to more self-documenting code, too.

The patch in the RFC handles that with arrays as the collection, and 
run-time checking via type hints.  My initial thought was "yes please!", 
but from the discussion here I can see where that's sub-optimal for 
performance reasons as Rasmus notes.

Generics or something in SPL would allow for simpler add-time checking, 
which is what we probably want.  However, if we did that then all of the 
various array functions don't work.  That's hardly a new problem for 
PHP, of course.

So how could we add "collection of just X type of things" support to PHP 
without running afoul of the "ArrayObject vs. Array" problem?

I'm not sure, but I think this is another case where "arrays as the 
uber-data structure" gets in the way of more robust programming 
methodologies.

--Larry Garfield