Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:71160 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 50445 invoked from network); 15 Jan 2014 22:00:38 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Jan 2014 22:00:38 -0000 Authentication-Results: pb1.pair.com smtp.mail=php@tutteli.ch; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=php@tutteli.ch; 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:47415] helo=hyperion.kreativmedia.ch) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 47/50-48719-30507D25 for ; Wed, 15 Jan 2014 17:00:36 -0500 Received: (qmail 5713 invoked from network); 15 Jan 2014 23:00:32 +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 23:00:32 +0100 To: "'Philip Sturgeon'" Cc: "'Marco Pivetta'" , "'Kristopher'" , References: <001301cf1227$6d082ab0$47188010$@tutteli.ch> <002d01cf1234$01e6dc60$05b49520$@tutteli.ch> In-Reply-To: Date: Wed, 15 Jan 2014 23:00:30 +0100 Message-ID: <004c01cf123d$35730870$a0591950$@tutteli.ch> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGahXeLh/KZbd8XAeJ9KP0Xitay+AEcU2WhAaqmqGABFinRgAGUH60GAsS5wSoDHy62oJqUvePQ Content-Language: de-ch Subject: RE: [PHP-DEV] Introducing "Array Of" RFC From: php@tutteli.ch ("Robert Stoll") > -----Original Message----- > From: Philip Sturgeon [mailto:pjsturgeon@gmail.com] > Sent: Wednesday, January 15, 2014 10:25 PM > To: Robert Stoll > Cc: Marco Pivetta; Kristopher; internals@lists.php.net > Subject: Re: [PHP-DEV] Introducing "Array Of" RFC > > On Wed, Jan 15, 2014 at 3:54 PM, Robert Stoll wrote: > > > > > >> -----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 > >> > >> On 15 January 2014 21:19, Kristopher wrote: > >> > >> > I think this implementation (MyClass[]) should be consistent this when > >> > passing null. > >> > > >> > >> 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`. > >> > >> Marco Pivetta > >> > > > > 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. > > > > > > > > I would assume that the majority of people will be using this syntax > to ensure the types of objects. > > In English: > > "I would like everything in this array to be Foo." > > That is much more programatically useful in my opinion than: > > "I would like everything in this array to be Foo or maybe null." > > If we go with the latter then I still have no idea what is in this > variable, and have to do a whole bunch of checking or > array_filter()ing, otherwise I am doing this: > > $possibleNullValue->getInfo(); // BOOM! > > Even if there are use-cases for allowing them I would suggest that > there are probably more use-cases for denying them. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php Fair enough, the example with the English sentence makes pretty much sense from an average user's point of view and thus most PHP users would probably agree with you (don't take it wrong, I don't imply you are average or something similar). However, this should not be a decision based on whether many people are preferring it this way or the other way round in my opinion, since the restriction is going to make it impossible to use it for the use cases where NULL is a valid entry. So, we should ask ourselves, do we really want to exclude a whole bunch of valid use cases or should we decline the restriction and put more effort in providing alternatives for non-null -containing collections. See, if we do not introduce the restriction and provide a non-null-containing collection then all use cases can be supported. That is the way to go IMO. Or do you have another idea how one can specify that the array can contain null? And please consider, if you should suggest "function foo(Foo[] $foo=null)" implies that $foo can also contain NULL then we have another vague concept in PHP which has a double meaning -> $foo can be NULL and entries in $foo can be NULL. But maybe one does not want to allow NULL for $foo but only for members of $foo.