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 [email protected] to get a copy of this message
On Wed, Jan 15, 2014 at 3:54 PM, Robert Stoll <[email protected]> wrote:
>
>
>> -----Original Message-----
>> From: Marco Pivetta [mailto:[email protected]]
>> Sent: Wednesday, January 15, 2014 9:25 PM
>> To: Kristopher
>> Cc: Philip Sturgeon; Robert Stoll; [email protected]
>> Subject: Re: [PHP-DEV] Introducing "Array Of" RFC
>>
>> On 15 January 2014 21:19, Kristopher <[email protected]> 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.


Thread (46 messages)

« previous php.internals (#71156) next »