Re: [RFC][DISCUSSION] Collection Inspection
| From: | Niklas Keller | Date: | Thu, 25 Jan 2018 21:04:30 +0000 |
| Subject: | Re: [RFC][DISCUSSION] Collection Inspection | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-101677@lists.php.net to get a copy of this message | ||
>
> On Thu, Jan 25, 2018 at 2:39 PM, Niklas Keller <me@kelunik.com> wrote:
>
>>
>> So, given
$a collectionof string the operator returns
>> whether or not $a
>>> is, at that time, a collection of strings (be it an array or other
>>> iterable). It doesn't insure $a will stay that way - it's just a check of
>>> the variables status at a given moment, which is the best that can be
>>> hoped
>>> for in PHP.
>>>
>>
>> That should be a function, not an operator, unless you can bring up very
>> good arguments to make it an operator.
>>
>
> Consistency with instanceof.
>
>
>
> Hmm, it might be possible to just pile this all onto instanceof -
> following Derrick's mention of how Java does things, so here's a third
> implementation approach. It would look like this:
>
> $a instanceof array<string>
>
That might work, but array<string> should only return true if it's an
array, not for anything that implements ArrayAccess.
> Returns true if $a is an array (or implements array access) and that all
> it's members are strings.
>
> $b instanceof SomeClass<string>
>
> Returns true if SomeClass can be iterated and contains only strings.
>
This would block generics with that syntax then.
> The question is can the token parser handle that pattern? Or does the
> current usage of < and > in their boolean form block this?
>
> If this third approach is accepted then we have no BC breaks at all since
> there's no new keyword or function. We just have a *very* expanded
> instanceof operator.
>
Regards, Niklas