Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91766
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 212.232.25.163 cause and error)
Reply-To: internals@lists.php.net
References: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>
 <CADyq6sKRFA667RA8Uzcx8SZ9x+GMEvoiX8S7QqrfV-fh0qgrGg@mail.gmail.com>
 <CADyq6sJxUrTQu__mQv-649cyvg4htzG+VK5g400b5-Vrvs5+TQ@mail.gmail.com>
 <56EC69EF.1090003@fleshgrinder.com> <56ECCFCB.6090105@garfieldtech.com>
To: internals@lists.php.net
Message-ID: <56ED28BD.4040900@fleshgrinder.com>
Date: Sat, 19 Mar 2016 11:23:57 +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: <56ECCFCB.6090105@garfieldtech.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="FOfjtfX9GSMk1eWhLGpRNPbWxl8WbtLBK"
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
From: php@fleshgrinder.com (Fleshgrinder)

--FOfjtfX9GSMk1eWhLGpRNPbWxl8WbtLBK
Content-Type: multipart/mixed; boundary="QAIDQlXbusflufi3GGq0TLL6P07v61BT7"
From: Fleshgrinder <php@fleshgrinder.com>
Reply-To: internals@lists.php.net
To: internals@lists.php.net
Message-ID: <56ED28BD.4040900@fleshgrinder.com>
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
References: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>
 <CADyq6sKRFA667RA8Uzcx8SZ9x+GMEvoiX8S7QqrfV-fh0qgrGg@mail.gmail.com>
 <CADyq6sJxUrTQu__mQv-649cyvg4htzG+VK5g400b5-Vrvs5+TQ@mail.gmail.com>
 <56EC69EF.1090003@fleshgrinder.com> <56ECCFCB.6090105@garfieldtech.com>
In-Reply-To: <56ECCFCB.6090105@garfieldtech.com>

--QAIDQlXbusflufi3GGq0TLL6P07v61BT7
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 3/19/2016 5:04 AM, Larry Garfield wrote:
> On 03/18/2016 03:49 PM, Fleshgrinder wrote:
>> First a general note on the complete nullability first: It is not up t=
o
>> us as language designers to decide whether it is good practice to use
>> nullable properties or not. It is supported by many systems since ages=

>> (e.g. SQL where nullable fields are also not recommended but heck they=

>> are useful) and it is common practice in PHP. Hence, there must be
>> support for it. That does not mean that it is endorsed in any way by u=
s,
>> it is just there for people who need it for the same reasons they need=
ed
>> it in the past 20 or so years.
>=20
> At the risk of a small tangent, I cannot agree at all here.  The whole
> point of language design is to make decisions regarding what "good
> practices" to encourage, enforce, or disallow.  Some languages disallow=

> mutable variables (despite them being useful).  Some languages disallow=

> global variables (despite them being occasionally useful).  Some
> languages disallow NULLs (despite them having use cases in many
> languages).  Those are all viable and reasonable decisions for a
> language designer to make in various circumstances; to say that it's
> "not up to us as language designers" to make such decisions is to
> abdicate our responsibility as language designers.
>=20
> There may well be good arguments to allow property nullability. There's=

> also good arguments against it.  We'll decide one way or another.  But
> "we shouldn't take a position at all" is worse than taking a position,
> because that implicitly does take a position (allowing it), while
> pretending that we didn't.  Basically it means lying to ourselves about=

> it, which is never the right answer.
>=20
> Design is about making deliberate, informed decisions.  Let's make a
> deliberate, informed decision.
>=20
> To help with the informed part, can anyone speak to how other languages=

> handle null-typed properties?  I believe Java allows everything to be
> NULL (which sucks), but I'm not sure about other modern languages.  Can=

> anyone speak to that?  (I'd be particularly interested in Python, Go,
> and Rust, but any language you can speak to definitively would be
> valuable to know about.  Javascript and Ruby are, AFAIK, insufficiently=

> typed for the question to apply.)
>=20
> --Larry Garfield
>=20

Nope Larry, you are actually totally right and I am completely wrong.

I played around with the current implementation at https://3v4l.org/ and
some PHP voodoo that is required to work around missing access modifiers
for proper information hiding and I could not find a situation where
nullability was actually required nor beneficial at all.

I simply was still stuck in the beginning of the discussion where it was
asked in regards to invalid state after the construction and if
properties are allowed to be *void* (I call it now *void* to avoid my
own confusion with *null*) or not. Hence, I mixed that up and came to
completely wrong conclusions and a desperate argumentation towards
language design. I actually feel ashamed right now because that is truly
what language design is about and I was preaching that in other threads. =
:P

Properties need the ability to be void even after construction and it is
up to the object to keep track and ensure state. Nullability is imho not
necessary at all. So we are all in line here.

Only topics left (for me) are special features
(*mysqli_result::fetch_object* and *PDOStatement::fetchObject*) and
references.

I see solutions (summarized in other messages of mine) to all of them
but I do not see them being implemented or even thought about.

--=20
Richard "Fleshgrinder" Fussenegger


--QAIDQlXbusflufi3GGq0TLL6P07v61BT7--

--FOfjtfX9GSMk1eWhLGpRNPbWxl8WbtLBK
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

iQIcBAEBCAAGBQJW7SjEAAoJEOKkKcqFPVVrqD0P/jV2m29eVztERJXRQXqM97Vq
IZAxLCKIM5At0JmwQloOdYclR+aUAypXnCUZoYXdx4FcaP9VvU+U/yJu0VEua1cZ
wwwyQULGlzmZpRy/NAfVdBzzU2omgKdkU81Qu5CgtyGRwm7F27nZTk0wYplUlw7R
gw67aNO5dxd0r0IlvO6rNj585TwlyvyxIf7qDm+GnrfDaiCRStLVv0FtFBrOm+8o
Gf1dPdeGMEMPBr6m2/9YOMaX8PlqiPoJHGqJr8TmvDBDEgJ1MqmymzKCUTA3f2xw
KaFZsFROypFfnLuJ8Iv0kCIxxkjvDbsgF6qgWTo8sSAKtzHdAoB4Go7yLVe154Ss
8U4PqQayh8aCLhFPCKjK6dSx9QVr4q3n81uHWJ7pFI3+EL0Jo9sjeZxjzFBk9uJP
UUisji4DgzX+ZDdd/9fiNyducmegCj0+dxv6zJ2Msoob3+loDGzCM9YUurw5Zz82
Wn1Uc0YgkuO7RIlKNARoXrGTydLOLtMvOEutcaTJb5vha5/MTfrIX5ts62fAr6Fm
KqEw322S+aGTYwgtIR+IZKn+D6tavBLNz11GCDrfpcPirizEo4JkYMNfTAJrWtb0
R2lrFxIwk5RFWbaSwidhOkXVpc7LE3lT+nMEEqNKSOcIPknncO8/WUPX1X69nA3Z
PJrEIp5S0sZAama1CpQc
=wRnS
-----END PGP SIGNATURE-----

--FOfjtfX9GSMk1eWhLGpRNPbWxl8WbtLBK--