Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107186
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>
 <A38AACD1-013B-4D49-8A26-FDDEA9A2011D@newclarity.net>
In-Reply-To: <A38AACD1-013B-4D49-8A26-FDDEA9A2011D@newclarity.net>
Date: Tue, 17 Sep 2019 10:40:02 +0100
Message-ID: <CALKiJKq9eLvhKZf4ScBH_e3pLwMhKztYvNyOg+nzzLqY_agDZA@mail.gmail.com>
To: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d47ea20592bc8133"
Subject: Re: [PHP-DEV] Features related to Object Initializers
From: rowan.collins@gmail.com (Rowan Tommins)

--000000000000d47ea20592bc8133
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 17 Sep 2019 at 01:10, Mike Schinkel <mike@newclarity.net> wrote:

> But as I said before, naming is hard =E2=80=94 except for abstract exampl=
es 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 tha=
n
> starting with one and having to switch to the other makes a lot more sens=
e
> to me.
>
> 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 develo=
pment
>


There is a tip that I picked up somewhere that if you're struggling to name
something (e.g. a function or a class), it may be because you've defined
its responsibilities poorly, and it needs splitting or merging.

I, too, work with a legacy codebase that makes heavy use of $params arrays,
and I frequently see things like `$params =3D array_merge($product,
$customer); $params['sendEmails'] =3D true;` and then a bunch of functions
whose docblocks say basically "@param array $params No idea what's in this,
we just pass it on somewhere else". There is no better name for the $params
array because it has no particular responsibility, it's just a bag of data.

So I'm unconvinced by the anonymous class -> named class refactoring path
(and even more so with some of your further proposals like populating named
parameters from an object), because I don't actually want to end up with a
SomethingOptions object with 50 unrelated properties. What I want to end up
with is a function signature like doSomething(Product $product, Customer
$customer, bool $sendEmails). The step in between might look like
doSomething(Product $product, array $params) or even doSomething(array
$product, array $customer, bool $sendEmails) rather than doSomething(object
$params).


> rather than giving them only one option for anonymous class initializer,
e.g. the array initializer syntax?

I'm not a fan of (object)$array, or of stdClass in general, but I think the
solution to that is to expand the existing "new class" syntax with a way to
capture lexical variables.

I understand the desire to make a new syntax that does as much as possible,
but I think we have a few different combinations to achieve that:

- object initializers & simple anonymous class initializers look the same;
named parameters may or may not look similar; complex anonymous classes
have to use a different syntax
- object initializers are just constructors with named parameters;
anonymous class definitions don't look similar, but support both simple and
complex cases in one syntax

Either way, the whole set of features isn't going to be implemented in one
go, so we don't need to work out all the details, just a direction of
travel.


Regards,
--=20
Rowan Tommins
[IMSoP]

--000000000000d47ea20592bc8133--