Re: Introducing "Array Of" RFC

From: Date: Wed, 15 Jan 2014 21:24:30 +0000
Subject: Re: Introducing "Array Of" RFC
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to internals+get-71156@lists.php.net to get a copy of this message
On Wed, Jan 15, 2014 at 3:54 PM, Robert Stoll <php@tutteli.ch> 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 <kristopherwilson@gmail.com> 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.

« previous php.internals (#71156) next »