Re: Countable Type Hint

From: 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

« previous php.internals (#97084) next »