Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91763
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 212.232.28.125 cause and error)
Reply-To: internals@lists.php.net
References: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>
 <56E9C241.1090905@fleshgrinder.com> <56EC7CDF.8050002@dennis.birkholz.biz>
To: internals@lists.php.net
Message-ID: <56ED1244.2020206@fleshgrinder.com>
Date: Sat, 19 Mar 2016 09:48:04 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <56EC7CDF.8050002@dennis.birkholz.biz>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="KmCOqQU7HuduXrBuN37b95968pr1ooBAD"
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
From: php@fleshgrinder.com (Fleshgrinder)

--KmCOqQU7HuduXrBuN37b95968pr1ooBAD
Content-Type: multipart/mixed; boundary="hjh5jgE116SH00Q4nq4Rrui93Tt1gjSt8"
From: Fleshgrinder <php@fleshgrinder.com>
Reply-To: internals@lists.php.net
To: internals@lists.php.net
Message-ID: <56ED1244.2020206@fleshgrinder.com>
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
References: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>
 <56E9C241.1090905@fleshgrinder.com> <56EC7CDF.8050002@dennis.birkholz.biz>
In-Reply-To: <56EC7CDF.8050002@dennis.birkholz.biz>

--hjh5jgE116SH00Q4nq4Rrui93Tt1gjSt8
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 3/18/2016 11:10 PM, Dennis Birkholz wrote:
> Hi all,
>=20
> Am 16.03.2016 um 21:29 schrieb Fleshgrinder:
>> Another more complicated user case would be *mysqli_fetch_object* that=

>> populates the properties with values from a storage but values that
>> should become something specific and strict at some point but are
>> initially populated as strings. Type coercion would be a nice thing he=
re
>> but with strict checks afterwards.
>=20
> I really don't like the special way mysqli and PDO use here.
> Both should use the __set_state() magic method as would any userland co=
de.
> But that is a discussion for another thread ;-)
>=20
> Greets
> Dennis
>=20

I think the discussion is important here because the introduction of
typed properties as proposed would break exactly this functionality of a
few of the most used extensions of all.

That being said, I agree and disagree at the same time with you on
*__set_state*. I also would prefer it if these methods would call
another method because they always require a check:

    final class A {
        private $x;
        private $y;

        private function __construct(O $x =3D null, O $y =3D null) {
            // mysqli_result::fetch_object
            // PDOStatement::fetchObject
            if (isset($this->x)) {
                $this->x =3D new O($this->x);
                $this->y =3D new O($this->y);
            }
            else {
                assert(isset($x));
                assert(isset($y));
                $this->x =3D $x;
                $this->y =3D $y;
            }
            // Some assertions on $x and $y ...
        }

        public static function new($x, $y, ErrorNotifier $n) {
            // Expensive validation ...
            return new static($x, $y);
        }

        public static function __set_state(array $data) {
            return new static($data['x'], $data['y']);
        }
    }

Of course there are other ways to implement this. I just want to
illustrate that it is not an ideal situation if we want to keep our code
as DRY as possible while using automated type checks without assertions.
But back to the *__set_state* problem. *__set_state* expects that the
members of the passed array are fully initialized because it is the
inverse of *var_export*. The data that is provided by
*mysqli_result::fetch_object* and *PDOStatement::fetchObject* are not
fully initialized so they are not good candidates to use *__set_state*.

Using another magic method would solve the riddle:

    final class A {

        private $x;
        private $y;

        private function __construct(O $x, O $y) {
            // Some assertions on $x and $y ...
            $this->x =3D $x;
            $this->y =3D $y;
        }

        public static function new($x, $y, ErrorNotifier $n) {
            // Expensive validation ...
            return new static($x, $y);
        }

        // mysqli_result::fetch_object
        // PDOStatement::fetchObject
        public static function __init_state(array $data) {
            return new static(new O($data['x']), new O($data['y']));
        }

        public static function __set_state(array $data) {
            return new static($data['x'], $data['y']);
        }
    }

Both examples might be bad but they are everything I just could come up
with.

TL;DR *__set_state* is not the correct method in this case because it is
the inverse of *var_export* and expects all members to be fully
initialized what is definitely not the case for both
*mysqli_result::fetch_object* and *PDOStatement::fetchObject*.

--=20
Richard "Fleshgrinder" Fussenegger


--hjh5jgE116SH00Q4nq4Rrui93Tt1gjSt8--

--KmCOqQU7HuduXrBuN37b95968pr1ooBAD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJW7RJHAAoJEOKkKcqFPVVr580QAJF2OdoNAnYiTpAkqhMx15Fe
basGePBp7g8IWo8ryA0jV2foB5Gn6MedSyxTX19POnVaj+IrHCI/1ktOCnRg5zfK
Bgh6Ixvhem6TXtzT8OZeljmSmhRpsJxZnQvki0Wg9NjzpJSBmiLocyWL03pOBaaQ
4TVi+1xE3o2JJ1R1Pmpt9fhgFt8QJAG7FA4ZWFd8p92L7gG3STpjic9TMojA0gHt
9MUANlYaGhqQDLbamDf+vhS8tsE5ZmC7J+MtLlxYnQVKPC466/Lt5cy5pQFOsoNW
02fNgM/UUEOd89e1fLS2nQMSBv64Er2s6Um0/31ephwmHm7cKslIPiCaazu0Xy72
K4T36tBrS+gdEZ53m8Ym2/r6rNVuBYGpMkO3BY10NEbCGmPWzLj8FZToMB+QZW+D
XCRjlYs/5Sokr9NmPC75sBGrrLavLeBqcTcxh+HlKvjIYGuI+gmWn8driy1rZk9d
6laC/nykKUYPgf3aPospPBbeQ/5rj2tLwtG63aE0Svv+GiTzuQkvjv37MxSemj9t
CtYV7nBplYRYZH+j0Ci09HFedG//Ri7WvQcKZFLIgRglrOTMwQtWHeOSvnzfnu92
3uT65RH7+Xg6lDPpgTFdGmkoLpTH+BL8FYQhoDb4zLXOjUzlX/V//pSQ9DdXumn5
uy20SrzqdKzkxheZ+YpB
=z2HG
-----END PGP SIGNATURE-----

--KmCOqQU7HuduXrBuN37b95968pr1ooBAD--