Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:71155 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 40693 invoked from network); 15 Jan 2014 20:54:44 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Jan 2014 20:54:44 -0000 Authentication-Results: pb1.pair.com header.from=php@tutteli.ch; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=php@tutteli.ch; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain tutteli.ch designates 80.74.154.78 as permitted sender) X-PHP-List-Original-Sender: php@tutteli.ch X-Host-Fingerprint: 80.74.154.78 ns73.kreativmedia.ch Linux 2.6 Received: from [80.74.154.78] ([80.74.154.78:46458] helo=hyperion.kreativmedia.ch) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 88/49-26701-395F6D25 for ; Wed, 15 Jan 2014 15:54:44 -0500 Received: (qmail 6655 invoked from network); 15 Jan 2014 21:54:40 +0100 Received: from heim-032-99.raab-heim.uni-linz.ac.at (HELO RoLaptop) (193.171.32.99) by ns73.kreativmedia.ch with (AES128-SHA encrypted) SMTP; 15 Jan 2014 21:54:40 +0100 To: "'Marco Pivetta'" , "'Kristopher'" Cc: "'Philip Sturgeon'" , References: <001301cf1227$6d082ab0$47188010$@tutteli.ch> In-Reply-To: Date: Wed, 15 Jan 2014 21:54:39 +0100 Message-ID: <002d01cf1234$01e6dc60$05b49520$@tutteli.ch> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGahXeLh/KZbd8XAeJ9KP0Xitay+AEcU2WhAaqmqGABFinRgAGUH60GmsPLJ0A= Content-Language: de-ch Subject: RE: [PHP-DEV] Introducing "Array Of" RFC From: php@tutteli.ch ("Robert Stoll") > -----Original Message----- > From: Marco Pivetta [mailto:ocramius@gmail.com] > Sent: Wednesday, January 15, 2014 9:25 PM > To: Kristopher > Cc: Philip Sturgeon; Robert Stoll; internals@lists.php.net > Subject: Re: [PHP-DEV] Introducing "Array Of" RFC >=20 > On 15 January 2014 21:19, Kristopher = wrote: >=20 > > I think this implementation (MyClass[]) should be consistent this = when > > passing null. > > >=20 > Even without the argument of consistency, the new syntax would be = pretty > much useless if `NULL` was allowed, since every method would have = start > with a call to `array_filter`. >=20 > Marco Pivetta >=20 You could also think in a different way. NULL is basically a valid entry = in an array. If you apply the restriction as implemented in the pull = request then one cannot use the new syntax for arrays which allow NULL, = that seems odd to me as well. Especially since class/interface-types are = reference types and I regard NULL as something equal to a null-pointer. Furthermore, if one does not want to support NULL in an array currently, = then one probably already uses an own collection implementation which = already triggers and error, throws an exception respectively, when one = tries to add NULL to the collection. It seems the pull request does not yet support multidimensional arrays = (e.g. Foo[][]) but if we would stick to the restriction now then the = consequence should be that this restriction also applies to = multi-dimensional arrays. In my opinion, we would spoil valid use cases = this way for RFC and for future ones (in the case multi-dimensional = arrays will be introduced, other concepts could be affected as well). Thus I would suggest to remove this check and provide a further SPL data = structure implementation instead which does not allow null as entry if = this feature is really needed. Seems more appropriate to me than making = a restriction in the language itself.