Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97084
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.221 cause and error)
MIME-Version: 1.0
In-Reply-To: <839cc149-cfb3-c164-7aa0-d29845f538b7@garfieldtech.com>
References: <CAHE1EdvM514MOvTRGU-CV2+hSAvtaOP+Q=xTH1z99EkyoZb+9w@mail.gmail.com>
 <CAFMT4NpZzbtJAC2eRgXwNrSP=-HFdGO_GOkgyGhBFLkLAReK1Q@mail.gmail.com>
 <CAKiSzdB5d9DCEVbx0ifbKo_QuX+zWZq+bPR2ARfw2HXpV1Jn8g@mail.gmail.com>
 <CAHE1Edu0C0ek6eq1RFRqXfiNwezD_Nr-ADvwdPC53P5VEa5b_w@mail.gmail.com>
 <CAKiSzdCm0yu10SQu4bgh4G5yX5CDnpThzdpaZH_zH+idM+V9Dg@mail.gmail.com>
 <b2c818cf-7978-61d3-c947-4881f705621b@gmail.com> <CANUQDChUZiQAyUi1BKeBeDdsVqNVk666p4V-V18w=-R0hj8scw@mail.gmail.com>
 <839cc149-cfb3-c164-7aa0-d29845f538b7@garfieldtech.com>
Date: Sun, 20 Nov 2016 14:24:44 +0100
Message-ID: <CANUQDChBV1xJucnc+YByZqV1=FHbaCOkj5HwBuUE2suCybgQxg@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1148e3866f47480541bb76e4
Subject: Re: [PHP-DEV] Countable Type Hint
From: me@kelunik.com (Niklas Keller)

--001a1148e3866f47480541bb76e4
Content-Type: text/plain; charset=UTF-8

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

--001a1148e3866f47480541bb76e4--