Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104478
MIME-Version: 1.0
References: <CAFPFaML36y=yf2y_j3VCJk7_uASc+cfLC1jHC_ipC0a_k+=2Fw@mail.gmail.com>
 <3247148.HBVCQ37Dhl@vulcan> <CALKiJKoL6g4qBDfdYSiWSo9Mb4jZO=VziMaCrNmWP090NGmh_g@mail.gmail.com>
 <5767621.reugzEP4TJ@vulcan>
In-Reply-To: <5767621.reugzEP4TJ@vulcan>
Date: Wed, 20 Feb 2019 18:09:05 +0100
Message-ID: <CAFPFaMLeLcLqAdVOG1B_FcF99mqkPDhGi0sNmtW3GobN6SkUbw@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ff3c870582566aa8"
Subject: Re: [PHP-DEV] Allows arrays to be type-hinted with interfaces
 mimicking Array behaviour
From: george.banyard@gmail.com (Girgias)

--000000000000ff3c870582566aa8
Content-Type: text/plain; charset="UTF-8"

On Tue, 19 Feb 2019 at 17:33, Larry Garfield <larry@garfieldtech.com> wrote:

> On Tuesday, February 19, 2019 3:38:16 AM CST Rowan Collins wrote:
> > On Tue, 19 Feb 2019 at 02:44, Larry Garfield <larry@garfieldtech.com>
> wrote:
> > > Yes, a lot of existing code uses arrays as anonymous structs.  Such
> code
> > > is,
> > > IMO, "doing it wrong".  That includes PHP default behavior in many
> cases.
> > > The
> > > super-globals are one of the exceptions, as since by definition you
> don't
> > > know
> > > what the keys could be in advance you need some sort of generic
> accessor.
> > >
> > > superglobals anyway on the grounds that globals are evil (fact check:
> > > true).
> > > There is often an object wrapping around the session that has get() and
> > > set()
> > > object be kind-of-array-ish-for-some-part-of-array-ish-ness is a
> > > long-standing
> > > problem, no question.  iterable was a good addition.  I think there was
> > > discussion of a countable type hint at one point, but I don't think it
> > > made it
> > > That leaves ArrayAccessible (aka, you can put [] after it and something
> > > useful
> > > happens), which is what you describe.  I would not be against adding
> such
> > > a
> > > instead of an object is Just Plain Wrong(tm).  Even a bare public
> property
> > > class is superior in every possible way, before we even get into
> questions
> > > of
> > > useful accessor methods.
> > >
> > > be.  (Eg, parsing JSON, GET or POST parameters, etc.)
> > > 2) You're being sloppy and not thinking through your API.
> > > struct into an object that has appropriate accessors that can then
> handle
> > > error cases, missing values, etc.  Not doing so results in things like,
> > > say,
> > > particular anonymous-struct was missing a certain key, which I didn't
> know
> > > was
> > > possible, but it broke the whole application.  (Seriously, that was my
> > > entire
> > > struct, even if you're using __get() or ArrayAccerss to do it.
> (SimpleXML
> > > is
> > > an example of that approach, for better or worse.)
> > > where you have to care, but those are edge-casey.
> > >
> > > ArrayAccessible is a code smell, and the solution is to properly
> structure
> > > your data and type hint on a defined class instead.  Including an
> > > ArrayAccessible pseudo-type would be just a matter of completeness, not
> > > something I would advise anyone actually use.
> >
> > Hi Larry,
> >
> > The above post seems to have been mangled somewhere and lost some of its
> > text. It's mostly readable anyway (and I think I agree with what's there)
> > but if you have a copy of the original anywhere, you might want to
> re-post
> > it.
> >
> > Regards,
>
> <expletive deleted>  No, I don't.  That's the second time KMail has eaten
> half
> a message on me.  I am now officially in the market for a new local mail
> client, because that's JUST NOT OK, KMAIL!
>
> The gist is that if you're dealing with unknown foreign data (JSON,
> GET/POST,
> etc.) you should be wrapping the raw structure into an object that
> provides a
> better interface, default value handling, error handling, etc.  If you
> know
> what the keys are in advance, make it an explicit class, period.
>
> So while I would be OK with an ArrayAccessible type hint for completeness,
> I
> would view using it as a code smell.
>
> Insert debate about union types here, as it's bound to come up at this
> point.
>
> Excuse me while I go find a new Linux mail client that isn't a buggy data-
> losing <censored>.
>
> --Larry Garfield


In all honesty the idea/proposal was more for completeness than anything
else.
I do think I can agree with you that ArrayAccess is *probably* a code smell.
But my initial email was more to see if this would get any support and
secondly
to see how to implement this. Because as said using pseudo types are (from
my
understanding) easy to implement but could possibly limit the scope of new
Array like
interfaces (not sure if it is practical at all but as an idea Sortable
and/or Comparable, even
tho comparable probably needs a whole pseudo type on its own to accepts
strings, integers
floats and what's not) whereas some other possible (from my limited
understanding) could
be more bullet proof to future change.

But I suppose one question is if PHP want's to continue to encourage usage
of the ArrayAccess
(and other array like interfaces) for objects. I could well see an argument
for a ``countable`` pseudo
type if decided ArrayAccess as an interface "should" be scrapped as you say
leads to code smell.

Anyway thanks again for the feedback.

Best regards

George P. Banyard

--000000000000ff3c870582566aa8--