Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107177
Message-ID: <83819928-59BF-4C02-9F97-59306EE97F90@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_3A509B20-936B-4CFD-9A9A-617FFC5EDE56"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 16 Sep 2019 15:28:52 -0400
In-Reply-To: <CF8F19DB-7429-473B-AB39-EFD869BF327E@newclarity.net>
Cc: PHP Internals List <internals@lists.php.net>
To: Rowan Tommins <rowan.collins@gmail.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>
Subject: Re: [PHP-DEV] Features related to Object Initializers
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_3A509B20-936B-4CFD-9A9A-617FFC5EDE56
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I had to snip context and split in two to get under the 30k char limit.=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 have.
> Point 2 is a bit vague; is your point essentially "if we had nicer =
syntax
> for anonymous classes people would use them more"? If so, then see =
next
> section; if not, I'd like more clarification on what you were trying =
to
> illustrate with your "nested parameters" example.

The primary point here was:

"If we had an easier syntax for object initializers, people would be =
more likely to use them instead of using arrays"

Note I said "object initializers" not "anonymous classes" because the =
alternative is people using arrays.=20

And that is one of reasons things I really want object initializers; so =
that developers who use arrays for structured data will be more likely =
to use objects instead. Myself included.

> The problem with trying to make anonymous class declarations and =
object
> initalizers look and feel similar is that there's a lot more that can =
go
> into an anonymous class declaration: types, visibility, methods, =
traits,
> "extends" and "implements" clauses, etc.=20

Good point about anonymous class declarations. =20

Frankly though, I personally (almost?) never use anonymous classes =
except for very simple ones because anonymous classes quickly because =
too complex. I find it much easier to reason about named classes at the =
point they need features like visibility, methods, traits, extends and =
implements clauses,

I see object initializers as a subset of anonymous class declarations. =
IOW, if declaring (what I will call) ad-hoc objects get too complicated =
then users will stop using them for the object initialization use-case. =
This is premised on the fact  I have usually seen less-zealous =
developers take the path of least resistance and arrays have been that =
path.

A lot of the code I have seen has been in WordPress plugins =E2=80=94 =
and some people on this list have made comments about them =E2=80=94 but =
if the PHP community wants to see them become better then making it more =
likely they will choose the better path will help improve them.

So if we get developers using objects instead of arrays, I think are =
will be more apt to recognize that they can benefit from declared named =
classes and move to those instead of objects. But if they are using =
arrays, I see no evidence that they will move to declared named classes.


> I think that's a good reason not to think of them as related features, =
unless
> you can think of use cases where having variable capturing in an
> anonymous class declaration would mean you would no longer want object
> initializers?

That question is confusing me given the context. Was there a typo/is it =
worded correctly?

> I'm a bit confused here whether we're talking about constructing =
objects of
> anonymous classes, named classes, or both. Your example showed =
constructing
> a defined Query object, but your comments above sound more like =
they're
> about using anonymous classes (as a replacement for arrays).

I understand your confusion; my fault. There are so many use-cases I =
have for object initializers that it is hard to stay focused on one =
specific use-case. And I have yet to give an example of one my primary =
use-cases given it's a coding pattern I might need to discuss first so =
it would be clear why object initializers would be so helpful.

I see object initializers being what beginners devs would start with, =
and what advanced devs would use is very ad-hoc use-cases. As beginners =
become intermediate they would start using basic named classes. And when =
they became more advanced they would start using features like =
visibility, traits, extends and implements.

So I envision it as a continuum, that IMO would be better if object =
initializers were just a simplified subset of anonymous classes rather =
than being an entirely different set of syntaxes to learn.

> Either way, I agree with the aim of making objects easier to =
construct, I'm
> just discussing the pros and cons of the various suggestions for doing =
that.

+1!

> As before, the definition of the class itself is simpler, but I think =
a
> short-hand syntax for constructors would be a better compromise than a
> syntax that only worked with public properties and parameterless
> constructors.


I think short-hand syntax for constructors would probably be a great =
feature oo, but do not think of them as satisfying any more than a few =
of the the use-cases for object initializers. =20

But before I can give examples, I need to know what you are thinking =
re:short-hand syntax for constructors?  =20

> I don't understand what you mean here. Your example showed a =
QueryBuilder
> class being refactored to use a Query object instead of multiple
> parameters, which is something that can happen right now, no language
> changes needed. The only new feature your example showed was a =
different
> way of constructing the Query class.

This is because of trying to come up with examples that address many =
different use-cases.  It is hard to come up with examples for all =
use-cases in one sitting.

> I agree, and I never said otherwise. I do think that an important part =
of
> deciding whether to implement a feature is evaluating its limitations, =
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 =
work
> with interfaces, I'm just saying that is a limitation to consider.

Understood.

1 of 2 ...continued=20

-Mike=

--Apple-Mail=_3A509B20-936B-4CFD-9A9A-617FFC5EDE56--