# Introducing "Array Of" RFC

- Thread: https://externals.io/message/71143
- Original archive: https://news-web.php.net/php.internals/71143
- Started by Philip Sturgeon on 2014-01-15T18:17:36+00:00
- Messages: 92
- RFC: Array Of (Declined) — https://externals.io/rfc/arrayof.md
- Page 1 of 4: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/71143.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #71143 — Philip Sturgeon — 2014-01-15T18:17:36+00:00

URL: https://externals.io/message/71143#71143

Hey,

This is my first RFC so give me a little leeway if I get things wrong.

https://wiki.php.net/rfc/arrayof

The implementation has been written by Joe Watkins, and I will be
handling the RFC process for him.

It is aimed at PHP 5.6, and so far the release managers seem to be ok
with the idea of this potentially being merged after the alpha
release, so this should not be considered an issue.

Everything is open for discussion, especially the current error
messages. They are not perfect, so let us know if you have better
ideas.

---

## #71144 — Andrea Faulds — 2014-01-15T18:21:43+00:00

URL: https://externals.io/message/71143#71144 · In reply to: #71143

> This is my first RFC so give me a little leeway if I get things wrong.
>
> https://wiki.php.net/rfc/arrayof
>
> The implementation has been written by Joe Watkins, and I will be
> handling the RFC process for him.
>
> It is aimed at PHP 5.6, and so far the release managers seem to be ok
> with the idea of this potentially being merged after the alpha
> release, so this should not be considered an issue.
>
> Everything is open for discussion, especially the current error
> messages. They are not perfect, so let us know if you have better
> ideas.

I think this is a great proposal.

I have one question, however. Though I doubt it would be a frequent 
usage, would { function (StdClass[][] $x) {} } work, for representing an 
array of arrays?
-- 
Andrea Faulds
http://ajf.me/

---

## #71145 — Robert Stoll — 2014-01-15T19:24:35+00:00

URL: https://externals.io/message/71143#71145 · In reply to: #71143

Hey,

> -----Original Message-----
> From: Philip Sturgeon [mailto:pjsturgeon@gmail.com]
> Sent: Wednesday, January 15, 2014 7:18 PM
> To: internals@lists.php.net
> Subject: [PHP-DEV] Introducing "Array Of" RFC
> 
> Hey,
> 
> This is my first RFC so give me a little leeway if I get things wrong.
> 
> https://wiki.php.net/rfc/arrayof
> 
> The implementation has been written by Joe Watkins, and I will be
> handling the RFC process for him.
> 
> It is aimed at PHP 5.6, and so far the release managers seem to be ok
> with the idea of this potentially being merged after the alpha
> release, so this should not be considered an issue.
> 
> Everything is open for discussion, especially the current error
> messages. They are not perfect, so let us know if you have better
> ideas.
> 
> --
> 
> 

First of all, I really like the RFC, good idea, well done.

But about some details. I am not sure if I got the implementation right (haven't done any code contributions so far, so
I am not really familiar with the source code) but it seems that a check for `NULL` is implemented for the actual
parameter which is perfectly fine (done for other type hints as well) but it also checks if all members of an array are
not `NULL` and the check returns a failure if `NULL` is detected. I think that's wrong, `NULL` is a perfect valid entry in an
array.

Furthermore, what about type hints like the following ones: 
function foo(int[] $qualities, callable[] $callables){}

Seems like they are not supported. But might be that I am totally wrong and did not understand the code

---

## #71146 — Andrea Faulds — 2014-01-15T19:27:03+00:00

URL: https://externals.io/message/71143#71146 · In reply to: #71145

> But about some details. I am not sure if I got the implementation right (haven't done any code contributions so far, so
> I am not really familiar with the source code) but it seems that a check for `NULL` is implemented for the actual
> parameter which is perfectly fine (done for other type hints as well) but it also checks if all members of an array are
> not `NULL` and the check returns a failure if `NULL` is detected. I think that's wrong, `NULL` is a perfect valid entry in an
> array.

I agree with this. `NULL` should be considered a valid substitute for a 
value of any type.

-- 
Andrea Faulds
http://ajf.me/

---

## #71147 — Robert Stoll — 2014-01-15T19:38:01+00:00

URL: https://externals.io/message/71143#71147 · In reply to: #71145

> 
> Furthermore, what about type hints like the following ones:
> function foo(int[] $qualities, callable[] $callables){}
> 
> Seems like they are not supported. But might be that I am totally wrong and did not understand the code
> 

Please forget about my question about type hint for int[], I forgot for a second that PHP does not support scalar type
hints.
However, the question about callable[] remains

---

## #71148 — Lazare Inepologlou — 2014-01-15T19:49:32+00:00

URL: https://externals.io/message/71143#71148 · In reply to: #71143

2014/1/15 Philip Sturgeon <pjsturgeon@gmail.com>

> Hey,
>
> This is my first RFC so give me a little leeway if I get things wrong.
>
> https://wiki.php.net/rfc/arrayof
>
> The implementation has been written by Joe Watkins, and I will be
> handling the RFC process for him.
>
> It is aimed at PHP 5.6, and so far the release managers seem to be ok
> with the idea of this potentially being merged after the alpha
> release, so this should not be considered an issue.
>
> Everything is open for discussion, especially the current error
> messages. They are not perfect, so let us know if you have better
> ideas.
>
>
Hello,

this is a nice proposal.

I hope that it is not limited to arrays only... All tranversables should be
acceptable (as they are acceptable for variadiac functions). Otherwise this
will lead to unnecessary (and costly) convertions.


Lazare INEPOLOGLOU
Ingénieur Logiciel

---

## #71149 — johannes@schlueters.de — 2014-01-15T20:03:52+00:00

URL: https://externals.io/message/71143#71149 · In reply to: #71148

> 
> 
> I hope that it is not limited to arrays only... All tranversables
> should be acceptable (as they are acceptable for variadiac functions).
> Otherwise this will lead to unnecessary (and costly) convertions. 

those can't be checked.

johannes

---

## #71150 — Nikita Popov — 2014-01-15T20:07:11+00:00

URL: https://externals.io/message/71143#71150 · In reply to: #71148

On Wed, Jan 15, 2014 at 8:49 PM, Lazare Inepologlou <linepogl@gmail.com>wrote:

> 2014/1/15 Philip Sturgeon <pjsturgeon@gmail.com>
>
> > […]
> Hello,
>
> this is a nice proposal.
>
> I hope that it is not limited to arrays only... All tranversables should be
> acceptable (as they are acceptable for variadiac functions). Otherwise this
> will lead to unnecessary (and costly) convertions.
>

An array is not just traversable - it is also array accessible and
countable, as well as passable-to-array-functions. Allowing to pass
Traversables to an array typehint violates the type constraint.

Nikita

---

## #71151 — Philip Sturgeon — 2014-01-15T20:09:45+00:00

URL: https://externals.io/message/71143#71151 · In reply to: #71145

> Hey,
>
> > […]
>
> First of all, I really like the RFC, good idea, well done.
>
> But about some details. I am not sure if I got the implementation right (haven't done any code contributions so far, so
> I am not really familiar with the source code) but it seems that a check for `NULL` is implemented for the actual
> parameter which is perfectly fine (done for other type hints as well) but it also checks if all members of an array are
> not `NULL` and the check returns a failure if `NULL` is detected. I think that's wrong, `NULL` is a perfect valid entry in an
> array.
>
> Furthermore, what about type hints like the following ones:
> function foo(int[] $qualities, callable[] $callables){}
>
> Seems like they are not supported. But might be that I am totally wrong and did not understand the code
>

Ok, ignoring the int stuff as PHP doesn't generally do that. We don't
want to broach that topic here.

As for allowing null, this feature is currently intended as a
syntactic representation of:

foreach ($foos as $foo) {
    if (! $foo instanceof Face) {
        throw new Exception ('AAAGGGGGHHH!');
    }
}

You are suggesting:

foreach ($foos as $foo) {
    if (! is_null($foo) and ! $foo instanceof Face) {
        throw new Exception ('AAAGGGGGHHH!');
    }
}

How do people feel about that?

---

## #71152 — Philip Sturgeon — 2014-01-15T20:10:56+00:00

URL: https://externals.io/message/71143#71152 · In reply to: #71148

>
>
> 2014/1/15 Philip Sturgeon <pjsturgeon@gmail.com>
> > […]
>
> Hello,
>
> this is a nice proposal.
>
> I hope that it is not limited to arrays only... All tranversables should be
> acceptable (as they are acceptable for variadiac functions). Otherwise this
> will lead to unnecessary (and costly) convertions.
>
>
> Lazare INEPOLOGLOU
> Ingénieur Logiciel
>
>
>
>

Currently function (array Foo) is ONLY arrays, not number of
interfaces will change that.

This RFC keeps to the same logic, but a later RFC could (and IMO
absolutely should) address this. I would suggest that this is a
different issue, and should be kept separate.

---

## #71153 — Kristopher — 2014-01-15T20:19:45+00:00

URL: https://externals.io/message/71143#71153 · In reply to: #71151

On Wed, Jan 15, 2014 at 3:09 PM, Philip Sturgeon <pjsturgeon@gmail.com>wrote:

>
> Ok, ignoring the int stuff as PHP doesn't generally do that. We don't
> want to broach that topic here.
>
> As for allowing null, this feature is currently intended as a
> syntactic representation of:
>
> foreach ($foos as $foo) {
>     if (! $foo instanceof Face) {
>         throw new Exception ('AAAGGGGGHHH!');
>     }
> }
>
> You are suggesting:
>
> foreach ($foos as $foo) {
>     if (! is_null($foo) and ! $foo instanceof Face) {
>         throw new Exception ('AAAGGGGGHHH!');
>     }
> }
>
> How do people feel about that?
>
>
PHP disallows passing `NULL` in a function like:

function foo(MyClass $obj) {}

Unless you explicitly allow it to be null:

function foo(MyClass $obj = null) { }

The first instance will throw an error:

PHP Catchable fatal error:  Argument 1 passed to foo() must be an instance
of MyClass, null given


I think this implementation (MyClass[]) should be consistent this when
passing null.

---

## #71154 — Marco Pivetta — 2014-01-15T20:25:08+00:00

URL: https://externals.io/message/71143#71154 · In reply to: #71153

> 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

http://twitter.com/Ocramius

http://ocramius.github.com/

---

## #71155 — Robert Stoll — 2014-01-15T20:54:39+00:00

URL: https://externals.io/message/71143#71155 · In reply to: #71154

> -----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
> 
> 
> 
> > […]
> 
> 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.

---

## #71156 — Philip Sturgeon — 2014-01-15T21:24:30+00:00

URL: https://externals.io/message/71143#71156 · In reply to: #71155

>
>
> > […]
>
> 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.

---

## #71157 — Lars Strojny — 2014-01-15T21:24:46+00:00

URL: https://externals.io/message/71143#71157 · In reply to: #71143

Hi Philip,


[...]
> 
> It is aimed at PHP 5.6, and so far the release managers seem to be ok
> with the idea of this potentially being merged after the alpha
> release, so this should not be considered an issue.
> 
> Everything is open for discussion, especially the current error
> messages. They are not perfect, so let us know if you have better
> ideas.

Very nice proposal. One thing I noticed by reading the code (and the tests9 is that it bails out at the first offender. Given I hint for Foo[], and pass [new Foo(), new Bar(), new Baz()] it will only inform me about Bar violating Foo. I would like to have a more descriptive error message that contains both Bar and Baz.

cu,
Lars

---

## #71158 — Lars Strojny — 2014-01-15T21:26:41+00:00

URL: https://externals.io/message/71143#71158 · In reply to: #71154

Hi Marco, everyone,


[...]
> 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`.

Very much true. Allowing null would introduce a huge hole for null pointer errors.

cu,
Lars

---

## #71159 — Nikita Nefedov — 2014-01-15T21:56:14+00:00

URL: https://externals.io/message/71143#71159 · In reply to: #71157

> Hi Philip,
>
> 
> [...]
> > […]
>
> Very nice proposal. One thing I noticed by reading the code (and the  
> tests9 is that it bails out at the first offender. Given I hint for  
> Foo[], and pass [new Foo(), new Bar(), new Baz()] it will only inform me  
> about Bar violating Foo.

So will calling foo(""); where foo's definition is foo(Asd $asd, Qwe $qwe);
I, for one, don't see a problem here.

---

## #71160 — Robert Stoll — 2014-01-15T22:00:30+00:00

URL: https://externals.io/message/71143#71160 · In reply to: #71156

> -----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
> 
> 
> > […]
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.
> > […]
> collection implementation which already triggers and error, throws an exception respectively, when one tries to add
 `NULL` 
> to the collection.
> > […]
> 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).
> > […]
> 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.
> 
> --
> 
> 

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.

---

## #71161 — Crypto Compress — 2014-01-15T23:18:32+00:00

URL: https://externals.io/message/71143#71161 · In reply to: #71160

Hello,

since there is an option for nullable type-hinted variables, it may be 
usefull to *explicitly* allow null values in a type-hinted array too.

e.g.: function foo(Bar[null] = null)

to consider:
- null is not an object
- null is not "nothing"
- null is not "not defined"
- null is not a/any type (even documentation states so)

Java: only reference types are nullable
c#: only if explicitly defined
sql: only if explicitly defined

cryptocompress

---

## #71163 — Andrea Faulds — 2014-01-15T23:54:22+00:00

URL: https://externals.io/message/71143#71163 · In reply to: #71161

> e.g.: function foo(Bar[null] = null)

I'd prefer the ? syntax for nullables that C# has. I'm imagining 
something like this:

function foo(Bar? $a) {}   // $a is Bar/null
function foo(Bar?[] $a) {} // $a is array of Bars/nulls
function foo(Bar[]? $a) {} // $a is array of Bars, or null
function foo(Bar?[]? $a) {} // $a is array of Bars/nulls, or null

-- 
Andrea Faulds
http://ajf.me/

---

## #71164 — Robert Stoll — 2014-01-16T00:09:29+00:00

URL: https://externals.io/message/71143#71164 · In reply to: #71163

> -----Original Message-----
> From: Andrea Faulds [mailto:ajf@ajf.me]
> Sent: Thursday, January 16, 2014 12:54 AM
> To: Crypto Compress; internals@lists.php.net
> Subject: Re: [PHP-DEV] Introducing "Array Of" RFC
> 
> 
> 
> 
> > […]
> 
> I'd prefer the ? syntax for nullables that C# has. I'm imagining
> something like this:
> 
> function foo(Bar? $a) {}   // $a is Bar/null
> function foo(Bar?[] $a) {} // $a is array of Bars/nulls
> function foo(Bar[]? $a) {} // $a is array of Bars, or null
> function foo(Bar?[]? $a) {} // $a is array of Bars/nulls, or null
> 
> --
> Andrea Faulds
> http://ajf.me/
> 
> --

I like Andrea's proposal, this way we can support all scenarios. 
It is possible to define that `NULL` is a valid entry in an array and we would stick to the same decision as for actual
parameters, namely that one has to define explicitly that null is a valid entry. This would make me happy and I suppose
also Philip.

Just as side notice, this syntax would also give the chance for PHP to get rid of the double meaning of "=null" in a
later version. I am talking about the following case:
function foo(Foo $a=null, $b=1){}
Where one might not want to specify that $a is optional but cannot do it differently at the moment - with the additional
? it could change :)

---

## #71171 — Martin Keckeis — 2014-01-16T09:18:01+00:00

URL: https://externals.io/message/71143#71171 · In reply to: #71164

2014/1/16 Robert Stoll <php@tutteli.ch>

>
>
> > […]
>
> I like Andrea's proposal, this way we can support all scenarios.
> It is possible to define that `NULL` is a valid entry in an array and we
> would stick to the same decision as for actual
> parameters, namely that one has to define explicitly that null is a valid
> entry. This would make me happy and I suppose
> also Philip.
>
> Just as side notice, this syntax would also give the chance for PHP to get
> rid of the double meaning of "=null" in a
> later version. I am talking about the following case:
> function foo(Foo $a=null, $b=1){}
> Where one might not want to specify that $a is optional but cannot do it
> differently at the moment - with the additional
> ? it could change :)
>
>
> --
> 
> 
>
>
+ 1 for the RFC

But if i'm not completely wrong, there is performance decrease instead of
increase in your tests?
https://gist.github.com/krakjoe/8444591

[joe@fiji php-src]$ sapi/cli/php isTest.php 10000
objects: 10000
arrayof:        0.00645113
instanceof:     0.00560713

---

## #71172 — php@tutteli.ch — 2014-01-16T10:01:27+00:00

URL: https://externals.io/message/71143#71172 · In reply to: #71171

> + 1 for the RFC
>
> But if i'm not completely wrong, there is performance decrease instead of
> increase in your tests?
> https://gist.github.com/krakjoe/8444591
>
> [joe@fiji php-src]$ sapi/cli/php isTest.php 10000
> objects: 10000
> arrayof:        0.00645113
> instanceof:     0.00560713

I gave the RFC a few more thoughts and came to the conclusion that it  
does not fit to PHP (due to the performance penalties involved).
The syntax merely hide an ugly design. If you would write the same in  
normal PHP then probably everyone would agree that it is bad design.
Following an example (doesn't really make sense but outlines the bad design)

function foo(Foo[] $foos){
    if(count($foos) > 0){
       $a = array_pop($foos);
       //do something
      foo($foos);
    }
}

Is equivalent to

function foo(array $arr){
    foreach($arr as $v){
       if(!($v instanceof Foo)){
          //trigger_error
       }
    }
    if(count($foos) > 0){
       $a = array_pop($foos);
       //do something
      foo($foos);
    }
}

The check adds runtime complexity to the function for each call which  
is obviously not necessary (once would be good enough). And I doubt  
that users would actually make sure that the check is only performed  
once and even if you would argue that one should write it as follows:

function bar(Foo[] $foos){
    foo($foos);
}
function foo(array $foos){
    if(count($foos) > 0){
       $a = array_pop($foos);
       //do something
      foo($foos);
    }
}

Then it is still bad design compared to a collection which actually  
does the check during the addition of elements.
Although, I like the effort to make PHP somewhat more type safe I am  
-1 for this RFC, the implementation respectively. If we want typed  
arrays then the array needs to carry the type to be efficient.

---

## #71173 — Chris Wright — 2014-01-16T10:04:42+00:00

URL: https://externals.io/message/71143#71173 · In reply to: #71157

> Given I hint for Foo[], and pass [new Foo(), new Bar(), new Baz()] it will
> only inform me about Bar violating Foo. I would like to have a more descriptive
> error message that contains both Bar and Baz.

While I see where you're coming from with this, it's non-trial to
implement this in a sane way, both in code and to handle every
possible scenario in a logical way. Suppose I pass an array or 10000
objects which instances of 10000 different classes which do not
satisfy the type hint? I guess you'd want to do something like

<= 3 offenders - give their class names and indices
> 3 offenders - give an error along the lines "passed array elements are completely wrong" (or maybe report first three and append a "and other errors")

...but IMO the complexity this would add is not worth the effort. From
a consistency point of view it should just use the same error logic as
the shiny new variadics feature - which also bails out at the first
offender.

Thanks, Chris

---

## #71174 — Jannik Zschiesche — 2014-01-16T10:38:35+00:00

URL: https://externals.io/message/71143#71174 · In reply to: #71160

Hi,


Am Mittwoch, 15. Januar 2014 um 23:00 schrieb Robert Stoll:

> 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.
> 
> 



if you pass an array which mixes both objects and null and you want to work on the objects, you still have to do the checks yourself:

function f (A[] $list)
{
    foreach ($list as $entry)
    {
        if (!is_null($entry))
        {
            $entry->doSth();
        }
    }
}


But in this case you could just omit the type hint and check it internally:

function f ($list)
{
    foreach ($list as $entry)
    {
        if (!is_null($entry) && ($entry instanceof A))
        {
            $entry->doSth();
        }
    }
}



The thought of this proposal is that the complete checking is done with just the type hint.
And allowing null would make this obsolete.

Also, you would then have the duplicated runtime impact:
you need to check the array twice:

1. check for null & A (type hint)
2. check for A

instead of just one. 



Cheers
Jannik

---

Next page: https://externals.io/message/71143.md?page=2