Re: Re: [RFC] "arrayable" pseudo type hint

From: Date: Tue, 04 Feb 2020 21:18:47 +0000
Subject: Re: Re: [RFC] "arrayable" pseudo type hint
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to internals+get-108402@lists.php.net to get a copy of this message
On Tue, Feb 4, 2020, at 12:40 PM, Aimeos | Norbert Sendetzky wrote: > Am 04.02.20 um 19:17 schrieb Rowan Tommins: > > I think Larry's point was that the flexibility of PHP's array type makes it > > really hard to pin down whether a given object is "array-like" or not, and > > which attributes a particular function actually cares about. > > What else besides array access, counting and traversing is possible that > may differ from classes that implement those interfaces? > > > A general "intersection type" system might be more useful, because then you > > could require the parts you specifically needed, such as > > "traversable&ArrayAccess" or "traversable&countable". > > I think that's too complicated and we should make it as easy as possible > for PHP developers. > > Also, there's already an RFC for intersection types but it was never > adopted: https://wiki.php.net/rfc/intersection_types Rowan is exactly right and said it better than I did. The point is that "I can count() it", "I can foreach() it" and "I can bracket it" are three different things; in practice, a given function likely only cares about one, maybe two of those at a time. Adding a type for "an object that mimics all of the dumb things arrays do, but now passes differently" doesn't strike me as useful; it strikes me as the sort of thing I'd reject in a code review if someone tried to do it in user space. The problem with PHP arrays is that they're not arrays; they're a hash map with poor safety, lame error semantics, and some cheats to make them kinda sorta look like arrays if you don't look too carefully. In practice, they create more bugs than they fix. Intersection types would be absolutely delightful and I want them for numerous reasons. --Larry Garfield

« previous php.internals (#108402) next »