2016-11-19 19:18 GMT+01:00 Larry Garfield <la...@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
