Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91786
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 212.232.25.162 cause and error)
Reply-To: internals@lists.php.net
References: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>
 <56E9C241.1090905@fleshgrinder.com> <3B.AA.03097.757BDE65@pb1.pair.com>
To: internals@lists.php.net
Message-ID: <56EEA379.20503@fleshgrinder.com>
Date: Sun, 20 Mar 2016 14:19: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: <3B.AA.03097.757BDE65@pb1.pair.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="AExmUmKL8MFmjREASxlgP5FD03OV3s00W"
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
From: php@fleshgrinder.com (Fleshgrinder)

--AExmUmKL8MFmjREASxlgP5FD03OV3s00W
Content-Type: multipart/mixed; boundary="ovj8tACjRivhsUGoJUxA6A7vnaMqbwe4h"
From: Fleshgrinder <php@fleshgrinder.com>
Reply-To: internals@lists.php.net
To: internals@lists.php.net
Message-ID: <56EEA379.20503@fleshgrinder.com>
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
References: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>
 <56E9C241.1090905@fleshgrinder.com> <3B.AA.03097.757BDE65@pb1.pair.com>
In-Reply-To: <3B.AA.03097.757BDE65@pb1.pair.com>

--ovj8tACjRivhsUGoJUxA6A7vnaMqbwe4h
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 3/19/2016 9:32 PM, Andrea Faulds wrote:
> Hi,
>=20
> Fleshgrinder wrote:
>> 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 b=
e
>> 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 simpl=
y
>> 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?
>=20
> This is actually a problem for optimising PHP. If the compiler cannot b=
e
> sure a property's value actually matches its declared type, it can't
> optimise operations on that property to remove a type check.
>=20

Can we optimize operations or is this theoretical?

On 3/19/2016 9:32 PM, Andrea Faulds wrote:
> I also think it would be unintuitive if typed properties had some
> exception where they don't obey the given type. If I ask for an integer=
,
> then surely I should get an integer?
>=20

Of course but there is some *void* time until an object is fully
initialized. We've seen many examples now in this thread.

On 3/19/2016 9:32 PM, Andrea Faulds wrote:
>>
>> 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. 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 kil=
l
>> 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.=

>=20
> This adds a loophole to property type checks which, as previously
> mentioned, prevents us from performing optimisations. I also don't see
> why internal functions should be treated specially here, given that
> surely one could write userland code with the same needs as MySQLi? It
> doesn't seem intuitive.
>=20

It is just code that exists and is used and I am trying to find a
solution for it together with this new feature. I already wrote that I
would highly prefer that *mysqli_result::fetch_object* and
*PDOStatement::fetchObject* work differently but I am not the maintainer
and I cannot tell if they are willing to change their behavior.

The auto-mapping these methods provide is in general an extremely nice
thing to have. Plus it is much faster than a comparable userland
solution; which is of course implementable.

On 3/19/2016 9:32 PM, Andrea Faulds wrote:
>> 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 argument=
s
>> since ages and it directly could solve the Nullable problem mentioned =
in
>> future scope.
>=20
> We could certainly do this, but I'm not sure we should. Like for
> arguments, this would mean that your default value must be null, and yo=
u
> don't have to assign to it. But what if you want a different default
> value? What if you want to require it be assigned to?
>=20
> Adding a syntax form for nullable types (e.g. `?int` or `int|null`)
> would avoid these issues, and also solve the nullable return type issue=
=2E
>=20

You are absolutely right I did not think about that. But currently it
seems as if nobody (including me) wants nullable types anyways.

On 3/19/2016 9:32 PM, Andrea Faulds wrote:
>> 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 no=
t
>>> be using properties as part of their public API".
>>>
>>
>> An ini setting to control type checks and hints would be a nice thing =
to
>> have.
>=20
> An INI setting to control type checks is impractical, because it would
> affect all PHP code running in a given PHP interpreter. This means you
> control not only the type checking mode of your own code, but also of
> all the libraries you're using. Unless you never use other people's
> code, using this INI setting would just break things.
>=20
>> 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
>=20
> Why would you want to disable type checks altogether? There might be a
> small performance improvement, but you've removed important error
> checking. What if something goes wrong at runtime?
>=20
>> Where 1 would be the default since the default should be for developme=
nt

This should have been 2.

>> 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/scala=
r
>> type checks/hints.
>=20
> This solves a problem which I don't believe exists. The system PHP 7 ha=
s
> means that if you don't want to use strict types, they never affect you=
=2E
>=20
>>
>> 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.
>=20
> Yes, the declare() approach is unusual compared to other settings.
> That's because it was designed so the choices your code makes doesn't
> affect other code which uses it. In the Composer era, this matters,
> because a lot of code your interpreter is running will not be written o=
r
> maintained by you.
>=20
> Thanks.
>=20

I just though its nice to have the setting without having a strong
opinion about it.

--=20
Richard "Fleshgrinder" Fussenegger


--ovj8tACjRivhsUGoJUxA6A7vnaMqbwe4h--

--AExmUmKL8MFmjREASxlgP5FD03OV3s00W
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

iQIcBAEBCAAGBQJW7qOPAAoJEOKkKcqFPVVrKBcP/R9nj1qaBRWzyMwCDMBIDomx
aFYVbE3iMQsfrFagW0WAm0Flcx4O48u0bgJjW8wjL09ZNX2aQ+2eTL/o+hdcCJta
2TJba6952k5ep+302Ia91bmRo0so35LU5SiTTdY4nKNy2D4yhuFYa00F7s0wKV07
oLQdn81jcsR3e+tLXzzMvC6cbg/eYuYxidYyNVieHb5C6MeILQHtgp5T1wNp4QQ9
PqbfmiVfiVWGKpTS6IfkbEgJ80LOkuUetj9NzcvglKlt+kw6aMOLPglQ+3K6BGHr
bO42c/UIj27nwOhijRvOvTHIjTAagfKkirauibmvmkVmYG79qmKfSXrTDF7zD5iS
fsfYxnulg/SIIygYT6SR6pk/vVdTsrRJg3lErlGgsUOEbHx0tBE2fJ/XggbBZa92
r05gwnadd9lZi83eohV9M6KtFJKL0RqZfzsdJE3KIcNJKGW4GNVEScvY0vGzIb7j
WWiJ/jQPECKySbQpL5/Dz145c3HR/SZQWXDG0xjcI758fG+UUtTqcEylesOFRUDP
65/x0lmHVzLXZR0yLfa6eAfBeEkCd2qekOpXc5pqYDfV7sWUQMQin3X+gKGCAJrf
fQxrqQ/cxL9BasgClqhLvR1Ooc/6avr9ZVOvn7mgbn4BubyrO0z81rmJIMwsk/ix
0ClnMv/ufaKemtb+pUE0
=JZc6
-----END PGP SIGNATURE-----

--AExmUmKL8MFmjREASxlgP5FD03OV3s00W--