Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91712
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 212.232.28.126 cause and error)
Reply-To: internals@lists.php.net
References: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>
To: internals@lists.php.net
Message-ID: <56E9C241.1090905@fleshgrinder.com>
Date: Wed, 16 Mar 2016 21:29:53 +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: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="StI9jQSgTkAlCu6e9HSUNpiuE5nWNE9Pp"
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
From: php@fleshgrinder.com (Fleshgrinder)

--StI9jQSgTkAlCu6e9HSUNpiuE5nWNE9Pp
Content-Type: multipart/mixed; boundary="rc92sgvsoeOkETJRW0RRxQ4gHK7wEBhqa"
From: Fleshgrinder <php@fleshgrinder.com>
Reply-To: internals@lists.php.net
To: internals@lists.php.net
Message-ID: <56E9C241.1090905@fleshgrinder.com>
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
References: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>
In-Reply-To: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>

--rc92sgvsoeOkETJRW0RRxQ4gHK7wEBhqa
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Awesome feature thanks for the RFC. :)

On 3/16/2016 5:36 PM, Phil Sturgeon wrote:
> 1. How scared are we that integers can be expanded to floats on runtime=
?
>

This is already what happens in PHP all the time and I personally only
see harm if we change that. People are already not understand what the
difference between the two is and someone who is serious about this
topic is taking care of it on her/his own (many thanks to *intdiv*) or
is using strings anyways (*bcmath*/*gmp*).

On 3/16/2016 5:36 PM, Phil Sturgeon wrote:
> 2. This whole temporary nullability situation, where unset properties
> will error on attempted usage if not set. Should they instead error
> after the constructor has been called if they are still not holding a
> value?
>

I see a big problem with the erroring no matter when as others already
pointed out, e.g. together with named constructors (or factory methods
if you prefer that name) but also with lazy loading. I think that the
null value of properties during and after construction should simply be
ignored and left to the implementer. I know that it would be nice to
have 100% assurance that the property is always set but it would simply
result in rules that are too strict for various use cases. I mean,
aren't we trying to solve a problem that never was a problem here?

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 here
but with strict checks afterwards. Note that this cannot be handled by
the extension due to user types:

    final class Bar {

        private string $data;

        public function __construct(string $data) {
            $this->data =3D $data;
        }

    }

    final class Foo {

        private Bar $bar;

        private function __construct() {
            if (isset($this->bar)) {
                $this->bar =3D new Bar($bar);
            }
        }

    }

    $mysqli_result->fetch_object(Foo::class);

It is correctly populated with a string and the constructor changes it
to the desired instance. All fine, but the strict type check would kill
everything here.

I think that the strict type checks should start with the first
*userland* assignment and at no other point in time. The correct
initialization of an object is up to the implementer as it always was.

On 3/16/2016 6:27 PM, Chris Riley wrote:
> [...] how about some syntax which allows for a property to be null,
> or for it to be a specific type. I'd suggest a null assignment to
> fall in line with parameter type hints eg:
>
> class Foo {
>     protected int $bar =3D null; //can be null
>     private stdClass $baz; //can't be null
> }
>

This aligns nicely with the syntax that is present in PHP for arguments
since ages and it directly could solve the Nullable problem mentioned in
future scope. An example to illustrate how nicely it aligns with
existing PHP 5+ syntax:

    final class Foo {

        private int $bar =3D null;

        public function setBar(int $bar =3D null): void {
            $this->bar =3D $bar;
        }

    }

    (new Foo)->setBar(42);
    (new Foo)->setBar(null);

Additionally the extreme verbosity is super nice.

On 3/16/2016 5:36 PM, Phil Sturgeon wrote:
> 3. Weak vs Strict. Right now this is entirely strict, with no
> declare() to change mode. Reasons for this vary, from various sources,
> but include "Not sure how to implement it" and "Well people should not
> be using properties as part of their public API".
>=20

An ini setting to control type checks and hints would be a nice thing to
have. Like the checked mode of Google's Dart language. Such a setting
could and should also allow to disable type checks altogether, like we
have it with assertions:

    strict_types =3D -1 ; NOOP
    strict_types =3D 0  ; PHP 5 Style
    strict_types =3D 1  ; PHP 7 Coercion Style
    strict_types =3D 2  ; PHP 7 Strict Style

Where 1 would be the default since the default should be for development
and people who hate strict types just throw that zero in their ini and
are fine to reuse any code out there while ignoring all property/scalar
type checks/hints.

This would make the `declare` thingy pretty useless and I think it is
easier to understand. I thought that this approach was kind of weird
since its inception.

On 3/16/2016 6:39 PM, Johannes Schl=C3=BCter wrote:
> What about references? (yeah, references should die, but currently
> they still exist)
>
> What's expected here:
>
> class A {
>   public int $i;
> }
>
> $a =3D new A();
> $r =3D &$a->i;
> $r =3D "foobar";
>

I think this missing functionality is a blocker right now. Either we
have a plan to get rid of references altogether as Johannes mentions it
or the typed properties need support for it.

Note that the following currently works with the patch, which might lead
to more ranting in regards to missing/overlooked functionality if the
properties on their own do not support it.

    declare(strict_types=3D1);

    class A {

        private int $x =3D 0;

        public function &x(): int {
            return $this->x;
        }

    }

    $a =3D new A;
    $x =3D& $a->x();
    $x =3D 42;

    echo $a->x(); // 42

--=20
Richard "Fleshgrinder" Fussenegger


--rc92sgvsoeOkETJRW0RRxQ4gHK7wEBhqa--

--StI9jQSgTkAlCu6e9HSUNpiuE5nWNE9Pp
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

iQIcBAEBCAAGBQJW6cJGAAoJEOKkKcqFPVVr54EP/0WZbfFdVpzb6Guf5BBG94WV
vAOkMUiix4QRyCohuFFt5T7uv80P9Pwvg9NEaH2A3tXLktq2c59pQWXTo3UiOA1J
dQmCjr8oiCbgNRRJoiM/yiE+HuCgOnorJNQDT1exWWansU7MhHElosxBpi6GDWcv
EuYrgO72eAdNAlPdzksotSsCAtw7S/QJHu6578S9CvqxyC5D3RdPJkUczMDz26Rx
lQ6IlIhuf3n9/Nvh0CU0LDokcwPS6Cn0LO1TFsXtqHI5pijr0/LgJKV/471fYqDL
xQHLhlZZ+fZ7AeLmVxSBWhYbdMEkhWnsDJ5RoRL761NO/7yaKEZiN5Q9hERYq55s
MxYqpdLcYAXWGlqENaNOSPB/EazOZ3/DSPE5QoFgaxiYb11HOjXRhzs25WWvlNpy
Xy7qETA3iNXVnIBvI50LRaKlhwGKQ6mzE1zlzEnN+hmeMwg/AMreRT4YOcoPfjkP
YHVofFjJ5f7IXncE49jw9V7LK7/fHlf8+R+/AZrKDEiygVG2n4r1Ft+nfU9XFEkf
m8/c/oaA6ajq7nf9rxN5YfZJoJOyep90a/02fQJB1LioWk+b+FWhmEJkSKp0oIE3
LULfsEujMO6xk01zTmHrBmwsDqIPiybeH+gS+dt85Vwse8NJsAFsQYXLZsgGZo0P
FO0kDmKelWTH8v5U44kZ
=qPB2
-----END PGP SIGNATURE-----

--StI9jQSgTkAlCu6e9HSUNpiuE5nWNE9Pp--