Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108403
MIME-Version: 1.0
References: <861afae0-4568-745f-6615-a252067cc506@aimeos.com>
 <f0c665ca-02c3-da16-bb78-30d68f6e505e@aimeos.com> <5f5a4ab3-e609-4324-b056-53f782f1a63b@www.fastmail.com>
 <d9ed2493-0273-a4b2-7ec3-9aee06457325@aimeos.com> <CALKiJKr-ZHb4sqWERe=GAWJLkp_gcqGuaZoc06nz3=VPXrxY=A@mail.gmail.com>
 <2f37a761-9a54-b8b6-3bcb-39cf2224c227@aimeos.com> <f646c1a6-d1a1-432d-9334-30aeb6d77c87@www.fastmail.com>
In-Reply-To: <f646c1a6-d1a1-432d-9334-30aeb6d77c87@www.fastmail.com>
Date: Tue, 4 Feb 2020 23:24:36 +0100
Message-ID: <CAH0Uv3Ei6Pgd+rroPaxiuv07kzpQQzECGvgeg2McdVTjen5wSA@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000eeb53b059dc78157"
Subject: Re: [PHP-DEV] Re: [RFC] "arrayable" pseudo type hint
From: andreas@dqxtech.net (Andreas Hennings)

--000000000000eeb53b059dc78157
Content-Type: text/plain; charset="UTF-8"

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
>
>

--000000000000eeb53b059dc78157--