Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107182
User-Agent: Cyrus-JMAP/3.1.7-237-gf35468d-fmstable-20190912v1
Mime-Version: 1.0
Message-ID: <425cf402-370f-4d6f-9d9e-82a044b70c45@www.fastmail.com>
In-Reply-To: <83819928-59BF-4C02-9F97-59306EE97F90@newclarity.net>
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>
Date: Mon, 16 Sep 2019 17:20:51 -0500
To: "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: larry@garfieldtech.com ("Larry Garfield")

On Mon, Sep 16, 2019, at 2:28 PM, Mike Schinkel wrote:
> I had to snip context and split in two to get under the 30k char limit=
.=20
>=20
> > On Sep 16, 2019, at 6:22 AM, Rowan Tommins <rowan.collins@gmail.com =
<mailto:rowan.collins@gmail.com>> wrote:
> >=20
> > Points 1 and 3 are solved by anonymous classes, which we already hav=
e.
> > Point 2 is a bit vague; is your point essentially "if we had nicer s=
yntax
> > for anonymous classes people would use them more"? If so, then see n=
ext
> > section; if not, I'd like more clarification on what you were trying=
 to
> > illustrate with your "nested parameters" example.
>=20
> The primary point here was:
>=20
> "If we had an easier syntax for object initializers, people would be=20=

> more likely to use them instead of using arrays"
>=20
> Note I said "object initializers" not "anonymous classes" because the=20=

> alternative is people using arrays.=20
>=20
> And that is one of reasons things I really want object initializers; s=
o=20
> that developers who use arrays for structured data will be more likely=
=20
> to use objects instead. Myself included.
>=20
> > The problem with trying to make anonymous class declarations and obj=
ect
> > initalizers look and feel similar is that there's a lot more that ca=
n go
> > into an anonymous class declaration: types, visibility, methods, tra=
its,
> > "extends" and "implements" clauses, etc.=20
>=20
> Good point about anonymous class declarations. =20
>=20
> Frankly though, I personally (almost?) never use anonymous classes=20
> except for very simple ones because anonymous classes quickly because=20=

> too complex. I find it much easier to reason about named classes at th=
e=20
> point they need features like visibility, methods, traits, extends and=
=20
> implements clauses,
>=20
> I see object initializers as a subset of anonymous class declarations.=
=20
> IOW, if declaring (what I will call) ad-hoc objects get too complicate=
d=20
> then users will stop using them for the object initialization use-case=
.=20
> This is premised on the fact  I have usually seen less-zealous=20
> developers take the path of least resistance and arrays have been that=
=20
> path.
>=20
> A lot of the code I have seen has been in WordPress plugins =E2=80=94 =
and some=20
> people on this list have made comments about them =E2=80=94 but if the=
 PHP=20
> community wants to see them become better then making it more likely=20=

> they will choose the better path will help improve them.
>=20
> So if we get developers using objects instead of arrays, I think are=20=

> will be more apt to recognize that they can benefit from declared name=
d=20
> classes and move to those instead of objects. But if they are using=20=

> arrays, I see no evidence that they will move to declared named classe=
s.
>=20
>=20
> > I think that's a good reason not to think of them as related feature=
s, unless
> > you can think of use cases where having variable capturing in an
> > anonymous class declaration would mean you would no longer want obje=
ct
> > initializers?
>=20
> That question is confusing me given the context. Was there a typo/is i=
t=20
> worded correctly?
>=20
> > I'm a bit confused here whether we're talking about constructing obj=
ects of
> > anonymous classes, named classes, or both. Your example showed const=
ructing
> > a defined Query object, but your comments above sound more like they=
're
> > about using anonymous classes (as a replacement for arrays).
>=20
> I understand your confusion; my fault. There are so many use-cases I=20=

> have for object initializers that it is hard to stay focused on one=20=

> specific use-case. And I have yet to give an example of one my primary=
=20
> use-cases given it's a coding pattern I might need to discuss first so=
=20
> it would be clear why object initializers would be so helpful.
>=20
> I see object initializers being what beginners devs would start with,=20=

> and what advanced devs would use is very ad-hoc use-cases. As beginner=
s=20
> become intermediate they would start using basic named classes. And=20=

> when they became more advanced they would start using features like=20=

> visibility, traits, extends and implements.
>=20
> So I envision it as a continuum, that IMO would be better if object=20=

> initializers were just a simplified subset of anonymous classes rather=
=20
> than being an entirely different set of syntaxes to learn.
>=20
> > Either way, I agree with the aim of making objects easier to constru=
ct, I'm
> > just discussing the pros and cons of the various suggestions for doi=
ng that.
>=20
> +1!
>=20
> > As before, the definition of the class itself is simpler, but I thin=
k a
> > short-hand syntax for constructors would be a better compromise than=
 a
> > syntax that only worked with public properties and parameterless
> > constructors.
>=20
>=20
> I think short-hand syntax for constructors would probably be a great=20=

> feature oo, but do not think of them as satisfying any more than a few=
=20
> of the the use-cases for object initializers. =20
>=20
> But before I can give examples, I need to know what you are thinking=20=

> re:short-hand syntax for constructors?  =20
>=20
> > I don't understand what you mean here. Your example showed a QueryBu=
ilder
> > class being refactored to use a Query object instead of multiple
> > parameters, which is something that can happen right now, no languag=
e
> > changes needed. The only new feature your example showed was a diffe=
rent
> > way of constructing the Query class.
>=20
> This is because of trying to come up with examples that address many=20=

> different use-cases.  It is hard to come up with examples for all=20
> use-cases in one sitting.
>=20
> > I agree, and I never said otherwise. I do think that an important pa=
rt of
> > deciding whether to implement a feature is evaluating its limitation=
s, and
> > what use cases it would and wouldn't help with.
> >=20
> > I'm not saying this feature should never happen because it doesn't w=
ork
> > with interfaces, I'm just saying that is a limitation to consider.
>=20
> Understood.
>=20
> 1 of 2 ...continued=20
>=20
> -Mike

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 "Neve=
r* 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 a=
rrow-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 offer=
s basically no meaningful improvement except funnier passing semantics.

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 wi=
th *defined* classes with *defined* properties.  I think (although have =
not verified) that anonymous classes get the same benefit but iff their =
properties are explicitly defined like any other class.

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 def=
ined 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 develo=
per 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 sayin=
g "but now it's using objects".  For that, as noted, we already have an =
ample syntax that accomplishes just as much.

So rather than making it easier for people to make "anonymous structs th=
at use object syntax", we should be making it easier for people to defin=
e for-realsies named classes and using them, because *that* is where the=
 benefit comes from.

And for that part of the problem (making named struct-like classes easie=
r to work with), as noted in the other thread I find the named parameter=
s/auto-promotion combination to solve the problem just as well, and then=
 some.

--Larry Garfield