Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107184
Message-ID: <A38AACD1-013B-4D49-8A26-FDDEA9A2011D@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_82DF08EC-7077-4B6D-BB71-27DD8086808A"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 16 Sep 2019 20:10:40 -0400
In-Reply-To: <425cf402-370f-4d6f-9d9e-82a044b70c45@www.fastmail.com>
Cc: php internals <internals@lists.php.net>
To: Larry Garfield <larry@garfieldtech.com>
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>
Subject: Re: [PHP-DEV] Features related to Object Initializers
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_82DF08EC-7077-4B6D-BB71-27DD8086808A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On Sep 16, 2019, at 6:20 PM, Larry Garfield <larry@garfieldtech.com> =
wrote:
>=20
> I think everyone's in agreement about:
>=20
> 1) Making objects easier to work with.
> 2) Devs should use objects more.

I am glad we are reaching some common ground. :-)

> (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.)

Yes, I saw the article on your blog that you linked. Very nice. :-)

> However, why do we want devs to use objects more?  If we just want the =
arrow-like syntax, then this works today:
>=20
> $val =3D (object)[
>  'foo' =3D> 'bar',
>  'baz' =3D> 5,
> ];
>=20
> And now developers are using an anonymous "object".  However, that =
offers basically no meaningful improvement except funnier passing =
semantics.
> ...

> 2) They're more self-documenting and statically analyzable (by your =
IDE or any other tool)... but that's true only if you have an explicitly =
defined class!
> ...
> 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 "but now it's using objects".  For that, as noted, we =
already have an ample syntax that accomplishes just as much.


I can envision several benefits you do not mention, maybe because you've =
forgotten them, were not aware of them, or they did not occur to you?

In descending order of significance:

1. IDEs could validate local uses for stdClasses =E2=80=94 Given the =
following syntax, PhpStorm could and likely would implement an =
inspection that displayed a warning on the line with $val->bazoom =
because everything it needs to validate is there.  And I see no reason =
other IDEs could not do the same:

$val =3D stdClass{
    foo =3D> 'bar',
    baz =3D> 5,
};
echo $val->bazoom;

2. Empowering beginners =E2=80=94 If you are a beginner, or a =
work-to-live[1] programmer then I think there is a good chance you will =
find the syntax (object)[..] foreign and confusing.  I think they would =
find the following syntax easier to tackle and thus more likely to use, =
especially if they came from Javascript (note I omitted stdClass in =
hopes we could land on using such syntax for stdClass or anonymous =
classes):

$val =3D {
    foo =3D> 'bar',
    baz =3D> 5,
};

By empowering beginners they would be more likely to objects they can =
later refactor instead of arrays (see #5 below.)

3. Simplifying refactoring =E2=80=94 It will be easier to refactor an =
object initializer for stdClass to a declared class than to refactor =
from the hybrid array/object syntax.

4. Simplified syntax =E2=80=94 I tend to make a lot more typos when =
initializing array keys in PHP than I do when initializing objects in =
GoLang (the proposed PHP syntax is very similar to the equivalent in =
Go.)  Maybe I am unique in that, but I doubt it. =20

I also find array keys with quotes harder to read (but maybe that's =
because I have 56 year old eyes instead of younger eyes that guys like =
you have? :-)

5. The (object)[...] syntax feels like a hack =E2=80=94 I use that =
syntax, but every time I do I feel like I am doing something I should =
not be.  And I also rarely see that syntax being used in the wild, so =
maybe others feel the same?

5. PSON! =E2=80=94 I we had an object initializer syntax, we could =
finally have a competitor to JSON; i.e. PSON!  Imagine if we had only =
had it 15 years ago... :-o

Remember, the above were in descending order of significance.

> It's only an advantage if I do this:
>=20
> function doSomething(int $a, SomethingOptions $options =3D null) { ... =
}
>=20
> Doing that has many advantages, I think we all agree.  But going =
halfway doesn't give us any benefits other than swapping [' '] for ->.

Other than the assertion that it only has advantages with declared =
classes, I do generally agree this is usually the most beneficial =
approach.

But as I said before, naming is hard =E2=80=94 except for abstract =
examples where you can just name it "Something" :-) =E2=80=94 and =
developers often don't know what object schema they will need until they =
have written much of the code. So the ability to have a syntax that =
supports stepwise refinement rather than starting with one and having to =
switch to the other makes a lot more sense to me. =20

Allowing developers to start with doSomething(int $a, object $options =3D =
null) and then later refine the code to doSomething(int $a, =
SomethingOptions $options =3D null) creates less discontinuity for =
development rather than giving them only one option for anonymous class =
initializer, e.g. the array initializer syntax?

> So rather than making it easier for people to make "anonymous structs =
that use object syntax", we should be making it easier for people to =
define for-realsies named classes and using them, because *that* is =
where the benefit comes from.

If you can actually make it easy, I would be the first to support that. =
I just cannot envision how you can without more upfront complexity than =
simple object initializers need. =20

So please, prove me wrong! :-)

> 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/auto-promotion combination to solve the problem just as well, =
and then some.

There has recently been a call from several people on the list for =
everyone to try and find solutions that are not  "You loose so I can =
win." =20

Rather than protest object initializers to enable named =
parameters/auto-promotion instead, can we not work together to find a =
way to achieve all three with one simple syntax and as few new sigils =
used as possible?


-Mike
[1] That phrase came from one of my ex-girlfriends. It was derisive, and =
aim at me because I liked working. And note the qualifier "ex-."



--Apple-Mail=_82DF08EC-7077-4B6D-BB71-27DD8086808A--