Re: Countable Type Hint
| From: | Niklas Keller | Date: | Sun, 20 Nov 2016 13:24:44 +0000 |
| Subject: | Re: Countable Type Hint | ||
| References: | 1 2 3 4 5 6 7 8 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-97084@lists.php.net to get a copy of this message | ||
2016-11-19 19:18 GMT+01:00 Larry Garfield <larry@garfieldtech.com>:
> On 11/17/2016 10:12 AM, Niklas Keller wrote:
>
>> No, what Craig is proposing is a type hint that covers both the existing
>>> Countable interface and primitives which are naturally countable.
>>>
>>> If the union types RFC had passed, you'd be able to say
>>> "array|Traversable
>>> $foo"; a recent RFC lets you instead say "iterable $foo". The suggestion
>>> is
>>> to add a keyword which similarly acts as "array|Countable $foo".
>>>
>>> Unfortunately, as others have pointed out, it can't be called just
>>> "countable", because that's the name of the existing interface. The
>>> principle seems sound though, assuming we don't want to go down the route
>>> of treating arrays as implementing interfaces.
>>>
>>> I think it's better to implement method calls on primitives than
>> introducing new type keywords for every edge-case now. Once we have
>> methods
>> on primitives (counting array here as primitive), arrays can just
>> implement
>> the Countable interface and we're fine using Countable (the interface).
>>
>> Methods on primitives have the additional advantage that we can clean up
>> the API and have improved readability when chaining e.g. array methods
>> like
>> filter and map.
>>
>> Regards, Niklas
>>
>
>
> Methods on primitives has been proposed a few times, but never gone
> anywhere because it's, well, really hard to do. :-) Have you a
> recommendation for how to do so
What's the hard part about it? It's already possible with an extension:
https://github.com/nikic/scalar_objects
> (Honest question; I'd love primitive methods, especially if they're
> user-extensible.)
I don't know whether they should be user-extensible, probably not. It
prevents adding new built-in methods because of BC concerns. It might lead
to conflicting definitions in fundamental primitive operations (yes,
compare that with mbstring.func_overload). Also have a look at the JS world
and extending Object and Array.
Regards, Niklas