Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107188
MIME-Version: 1.0
References: <472D3E22-18D9-4C25-8961-C1DDEF482981@newclarity.net>
 <CALKiJKrDDJ1zrF5BVTpxCh3OO-1rgXiQ5aS7pY=Z6bFbFCC2xg@mail.gmail.com>
 <58673C6E-6632-42D9-BCBF-0294A62EB001@newclarity.net> <CF8F19DB-7429-473B-AB39-EFD869BF327E@newclarity.net>
 <83819928-59BF-4C02-9F97-59306EE97F90@newclarity.net> <425cf402-370f-4d6f-9d9e-82a044b70c45@www.fastmail.com>
In-Reply-To: <425cf402-370f-4d6f-9d9e-82a044b70c45@www.fastmail.com>
Date: Tue, 17 Sep 2019 12:57:56 +0200
Message-ID: <CAH0Uv3EKL+pdaaQb-zgB01uwza_+Rpoa3OCcE3PUjZ4JxArSqQ@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Features related to Object Initializers
From: andreas@dqxtech.net (Andreas Hennings)

On Tue, 17 Sep 2019 at 00:21, Larry Garfield <larry@garfieldtech.com> wrote=
:
> [..]
> I think everyone's in agreement about:
>
> 1) Making objects easier to work with.
> 2) Devs should use objects more.
>
> (Side note: I have an article submitted to php[architect] entitled "Never=
* use arrays" that goes into this topic in much more detail.  I am 100% on =
board with getting developers using objects more and arrays less.)
>
> However, why do we want devs to use objects more?  If we just want the ar=
row-like syntax, then this works today:
>
> $val =3D (object)[
>   'foo' =3D> 'bar',
>   'baz' =3D> 5,
> ];
>
> And now developers are using an anonymous "object".  However, that offers=
 basically no meaningful improvement except funnier passing semantics.

I would argue they can even be inferior to arrays.

Arrays have a big advantage over anonymous object, or even over any
mutable object:
They can be passed "by value", which protects them against pollution /
poisoning.
Objects are always passed as an instance pointer (I am not going to
say by reference here), which means they can always be modified in the
called function, unless they have been actively cloned beforehand.

Even classes that are designed to be immutable can still be poisoned
by setting anonymous properties.
Perhaps a future RFC could suggest a syntax to prevent that from happening =
:)

There are some other advantages of arrays, but they depend a lot on
the use case:
- Array syntax is more smooth for some use cases.
- Arrays can be counted, and compared vs the empty array.
- A type hint "array" excludes anything else. A type hint "\stdClass"
still allows any subclass of \stdClass, which could have its own
methods.

Otherwise, I agree: Objects with defined classes have many advantages
vs arrays or anonymous objects.
Depends on the use case of course. Arrays are still good for mapping
arbitrary keys to arbitrary values.

-- Andreas

>
> As I see it, the advantages of using objects over arrays are two fold:
>
> 1) The PHP engine is able to make dramatic optimizations when working wit=
h *defined* classes with *defined* properties.  I think (although have not =
verified) that anonymous classes get the same benefit but iff their propert=
ies are explicitly defined like any other class.
>
> 2) They're more self-documenting and statically analyzable (by your IDE o=
r any other tool)... but that's true only if you have an explicitly defined=
 class!
>
> So I see really no advantage whatsoever in replacing this:
>
> function doSomething(int $a, array $options =3D []) { ... }
>
> with this:
>
> function doSomething(int $a, object $options =3D {}) { ... }
>
> It's only an advantage if I do this:
>
> function doSomething(int $a, SomethingOptions $options =3D null) { ... }
>
> Doing that has many advantages, I think we all agree.  But going halfway =
doesn't give us any benefits other than swapping [' '] for ->.
>
> What we want to do is make it easier to create $options inline in a self-=
documenting way.  I'm all for that.  But that first requires the developer =
still define SomethingOptions somewhere.
>
> So for me, the entire "easier to use anonymous one-off classes" argument =
falls apart, because there's no material benefit there other than saying "b=
ut now it's using objects".  For that, as noted, we already have an ample s=
yntax that accomplishes just as much.
>
> So rather than making it easier for people to make "anonymous structs tha=
t use object syntax", we should be making it easier for people to define fo=
r-realsies named classes and using them, because *that* is where the benefi=
t comes from.
>
> And for that part of the problem (making named struct-like classes easier=
 to work with), as noted in the other thread I find the named parameters/au=
to-promotion combination to solve the problem just as well, and then some.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>