Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107087
Message-ID: <B55BB1F3-1E55-4324-A0E3-E4CD80CB19A7@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_7D480067-0A93-4188-A060-933428DF98ED"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sat, 14 Sep 2019 01:52:32 -0700
In-Reply-To: <0275793C-EC66-4693-B74F-B794E6FF0AC6@newclarity.net>
Cc: =?utf-8?Q?Micha=C5=82_Brzuchalski?= <michal.brzuchalski@gmail.com>,
 PHP Internals List <internals@lists.php.net>
To: Rasmus Schultz <rasmus@mindplay.dk>
References: <CABdc3Wpit02=BqvVE85ciw9qo3UYc2LBatOy23yFk5z+quZ2rw@mail.gmail.com>
 <CADqTB_gwv48eGO7tBLQkQ77BqUA0yJL_QG+DrY+nPzneXDTsvA@mail.gmail.com>
 <BD7D8174-FD06-4DD2-9C53-83F5E29D9428@newclarity.net>
 <0275793C-EC66-4693-B74F-B794E6FF0AC6@newclarity.net>
Subject: Re: [PHP-DEV] [RFC] Object Initializer
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_7D480067-0A93-4188-A060-933428DF98ED
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

(Sorry for sending three replies to one message, but the list server =
said my reply was too long to send as just one.=20
I could have made it shorter but then I would have had to omit all the =
example code.)

@rasmus:

HOWEVER, I see no reason we must pit object initializers and named =
parameters against each other as competing features.=20

I think there is benefit to both, and ideally could actually be two =
aspects of the same new feature.=20

Let me explain using one of your examples.

$car =3D new Car({ yearOfProduction =3D> 1975, vin =3D> "12345678"});

Conceptually let me ask, How is { yearOfProduction =3D 1975, vin =3D =
"12345678"} really any different from an instance of an anonymous class =
with the properties yearOfProduction and vin?=20

=46rom the recognition that named parameters that are collected as a =
group with braces ({}) are conceptually identical to anonymous class =
instances lets us to the insight we could use something like =
func_get_args(ARGS_OBJECT) to allow us to capture the grouped parameters =
as an instance of an object of anonymous class containing properties for =
each named parameter?

public function __construct(int $yearOfProduction, string $vin) {
   $args =3D func_get_args(ARGS_OBJECT);
   if ($args->yearOfProduction < 1900 ||  $args->yearOfProduction > =
date("Y")) {
      $msg =3D "year of production out of range:{$yearOfProduction}";
      throw new InvalidArgumentException($msg);
   }

   $this->yearOfProduction =3D $args->yearOfProduction;
   $this->vin =3D $args->vin;
}

Now assume we later realize we would be better passing in an instance =
instead of hardcoding the properties? We could change the signature, =
leaving all the rest of the code the same:

public function __construct(Customer $args) {
   if ($args->yearOfProduction < 1900 ||  $args->yearOfProduction > =
date("Y")) {
      $msg =3D "year of production out of range:{$yearOfProduction}";
      throw new InvalidArgumentException($msg);
   }

   $this->yearOfProduction =3D $args->yearOfProduction;
   $this->vin =3D $args->vin;
}

This is a critical capability in my book; the ability to refactor code =
to a more enlightened architecture without breaking it:

Of course if someone were to have used ordinal parameters when calling =
that constructor we could match their parameters to the properties of =
Customer in order of their declaration.=20

So the following maps 2019 to $yearOfProduction and "abc123xyz789" to =
$vin:

class Car=20
{
   public int $yearOfProduction;
   public string $vin;
   ...
}
$car =3D new Car(2019,"abc123xyz789");=20

The above could also now throw a warning so developers can find and =
replace all of those calls with calls that use the actual named =
parameters, but being a warning the code would still working until they =
update the calls.

> I'd prefer to see new features that work everywhere, all the time, for
> everyone - and for existing code. Rather than adding more features and
> syntax for very specific (even relatively rare) use-cases.

I completely agree with this statement, outside the context of your =
prior argument against object initializers.

Hopefully however, I have made the case that object initializers =
combined with named parameters would address a much broader range of =
use-cases than either of them would on their own?

-Mike


--Apple-Mail=_7D480067-0A93-4188-A060-933428DF98ED--