Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107133
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_182D5EF6-14B0-4B3A-9820-3A9695D4403F"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-ID: <472D3E22-18D9-4C25-8961-C1DDEF482981@newclarity.net>
Date: Sun, 15 Sep 2019 23:13:24 -0400
Cc: PHP Internals List <internals@lists.php.net>
To: Rowan Tommins <rowan.collins@gmail.com>
Subject: Features related to Object Initializers
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_182D5EF6-14B0-4B3A-9820-3A9695D4403F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> On Sep 14, 2019, at 4:47 PM, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
> I think that's only true because you've actually proposed a number of =
related but different features.


See my other email to the list asking about what is in-bounds and what =
it out-of-bounds regarding RFC discussion.

I seemed logical to me to discuss how to improve an RFC, but maybe what =
you are saying is that we are only suppose to discuss RFC as it exists =
today in order to give a black and white, up or down vote on the entire =
RFC?  That seems counter-productive, but if that is the case and others =
concur then so be it.

So to be safe, I have started a new thread for this reply.


> other than initializing additional objects. And if these are =
additional objects, then named parameters work just as well in the =
nested case as in the non-nested one:
>=20
> $car =3D new Car(
>   yearOfProduction =3D> 1975,
>   vin =3D> "12345678",
>   engine =3D> new Engine(
>      type =3D> "v8",
>      capacity =3D> "270ci",
>   ),
> );


Obviously that can be done. However, in practice I often see arrays used =
instead of objects because it is so much easier. I doubt that this =
enhancement will remove the other reasons developers might continue to =
use arrays instead:

1. Arrays do not require a developer to name a class, where naming is =
one of the 2 or 3 hardest parts of computer science

2. Anonymous classes  are more tedious than just creating an array =
literal so I see most PHP developers using arrays instead.

3. Defining a class in PHP best practice means creating another file =
that is physically separate from the code for said class that must also =
be (auto-)loaded.

So are you arguing that in all cases where people want structured =
information they should create a new class, and if so, what about the =
three points I just made?


> This already works:
>=20
> $stats =3D new class {
>    var int $total   =3D 0;
>    var int $mean    =3D 0;
>    var int $average =3D 0;
>    var int $median  =3D 0;
> };
>=20
> What doesn't currently work is using variables from lexical scope in =
the definition:
>=20
> $stats =3D new class {
>    var int $total   =3D $a + $b;
>    var int $mean    =3D $c;
>    var int $average =3D $d;
>    var int $median  =3D $e;
> };


In the USA we have a saying:

"Besides that Mrs. Lincoln, how was the play?"

But for those  unfamiliar with US history leading up to the =
revolutionary war, what it means in this context is:

"Yes your point is correct, but ignores the most relevant concern."

> However, initializer syntax on its own doesn't solve this, because you =
wouldn't be able to specify the types for the properties; just combining =
existing syntax with initializers would give something like this:
>=20
> $stats =3D new class {
>    var int $total;
>    var int $mean;
>    var int $average;
>    var int $median;
> }{
>    total =3D> $a + $a,
>    mean =3D> $c,
>    average =3D> $d,
>    median =3D> $e
> }

You probably missed that I wrote that I was using an alternate =
initialization syntax that I would propose instead, which I will =
illustrate again below. If we allow typing i

$stats =3D new class {
   int $total   =3D $a + $b;
   int $mean    =3D $c;
   int $average =3D $d;
   int $median  =3D $e;
};


> You could certainly make the syntax of initializers and anonymous =
class definitions similar, but they're not really the same thing.

Noted.  To me them being the same or not is not as concerning as the =
outcome of the features that may become available in userland.

> The QueryBuilder class in this example has not benefited from object =
initializers at all; passing the Query object rather than separate =
parameters is a refactoring you can (and probably should) do right now.

But many PHP developers are unlikely to do that refactoring initially. =
They will just fall back to using arrays, because they are easy, =
comfortable, less pedantic and less tedious to use.

I would far prefer to have find developers using untyped anonymous =
objects than arrays because the former is much easier to refactor to =
better code than the latter, and this is painfully obvious to me because =
of numerous PHP codebases I have been brought in to fix.

Would it be better to introduce a simple-to-use object instantiation =
syntax so userland PHP developers would start using it, or would it be =
better to leave them only one easy option such that they continue to use =
arrays?

> 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.

My problem with short-hand syntax for constructors is they only work in =
context of constructors. =20

What about other functions or methods that userland PHP developers =
currently pass structured arrays too?=20

> This is an interesting additional proposal, which I admit would be =
awkward to implement without initializer syntax. One limitation is that =
it only works if dependencies are declared as concrete classes not =
interfaces

True. =20

If a function is defined to accept an interface then the caller would be =
required to pass in an instance of a class that satisfies the interface.

> which like public properties is not "wrong" per se, but limits the =
scope of the feature.

If we had to have every feature work for everything, we'd never have =
`foreach,` for example.

My belief is that not every feature needs to apply in all contexts in =
order to be highly useful. Do you believe otherwise?

> Named parameters are (or would be) a way of setting a bunch of =
variables; they're not linked as an object of any sort, so I don't think =
there's a natural comparison to anonymous classes at all.

I did not say they _were_ linked, I asked why couldn't/shouldn't they be =
linked?

They are both a group of named "properties" with associated values. Why =
are they all not equivalent to an object?=20
And why not allow all of them to be treated as an object?

Even if there are represented different internally, I see no reason why =
they could not be made equivalent in userland code.  Do you?

> If I understand it right, the next example relies on the combination =
of anonymous class initialisers, named class initialisers, and named =
parameters all using the same syntax,=20

No, I would say that is not what I am proposing. What I am proposing is =
that one syntax and one set of functionality be used to address all =
three use-cases rather than have three different functionalities with =
three different syntaxes, because they seem to be to be all equivalent:=20=


1. anonymous class initialisers,=20
2. named class initialisers, and
3. named parameters=20

As Larry Garfield said, we are running out of sigils; making one syntax =
address multiple use-cases seems to me like the most responsible thing =
to do.

> The examples look really neat on their own, but imagine coming on that =
syntax in someone else's code and trying to work out what it was doing.

If I see someFunction({bar =3D> 1, baz =3D> 2}) that tells me that =
someFunction expects bar and bar as integers. When calling functions we =
are not supposed to know how they are implemented, so why should it =
matter to the caller whether internally they are captured to individual =
parameters or into a single parameter array?  And when inside the =
function, why does it matter how they are passed?

The reason I proposed this is I would really prefer to come on to this =
syntax in other's code rather than coming onto the prevailing type of =
code I see in userland instead; arrays upon arrays. =20

What is not clear to me is why you see it to be confusing?

> There's definitely some interesting ideas here, but they're not all =
part of one feature,

Can you clarify what you are implying?  That I should start other =
threads to discuss?  That I should create new RFCs?

> and they all rely on particular ways of structuring your code.

Is that problematic?  Most language features require code to be =
structured a particular way. =20

I am assuming that PHP is not an opinionated language that defines one =
way to structure code and shuns all other ways, except for those ways =
that have been explicitly deprecated by RFC such as magic quotes.  Am I =
incorrect about this?

-Mike

--Apple-Mail=_182D5EF6-14B0-4B3A-9820-3A9695D4403F--