Re: [PHP-DEV] Re: [RFC] "arrayable" pseudo type hint

This is only part of a thread. view whole thread
  108399
February 4, 2020 18:17 rowan.collins@gmail.com (Rowan Tommins)
On Tue, 4 Feb 2020 at 18:06, Aimeos | Norbert Sendetzky <norbert@aimeos.com>
wrote:

> Am 04.02.20 um 18:18 schrieb Larry Garfield: > > The more I think on it, the less I like `arrayable`. PHP arrays are > > a terrible data structure from a type system point of view, with too > > much functionality crammed into one variable type. > > The array internals are outside the scope of this proposal and are not > affected in any way by this proposal. >
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. 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". Regards, -- Rowan Tommins [IMSoP]
  108400
February 4, 2020 18:40 norbert@aimeos.com (Aimeos | Norbert Sendetzky)
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
  108402
February 4, 2020 21:18 larry@garfieldtech.com ("Larry Garfield")
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
  108403
February 4, 2020 22:24 andreas@dqxtech.net (Andreas Hennings)
On Tue, 4 Feb 2020 at 22:19, Larry Garfield <larry@garfieldtech.com> wrote:

> 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. >
There is one good thing about arrays: They are passed along by-value by default, which gives them similar qualities as an "immutable" object. If you pass an array to a function as a parameter which is not by-reference, you can expect the original array to remain unchanged. (Objects or referenced variables within that array can still be modified of course) A function parameter which allows an object OR an array loses this advantage. If I have the choice between \stdClass and array for "unstructured tree of data", I will always prefer the array. ~~ Andreas
> > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  108411
February 6, 2020 11:59 nikita.ppv@gmail.com (Nikita Popov)
On Tue, Feb 4, 2020 at 7:40 PM Aimeos | Norbert Sendetzky <
norbert@aimeos.com> 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 >
FWIW, that's an old RFC that predates the current implementation of union types in PHP 8 by a few years... A new proposal for intersection types should stand a better chance now, especially as it can mostly reuse the (relatively involved) technical underpinnings for the union types implementation. Nikita