Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93588
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 77.244.243.88 cause and error)
Reply-To: internals@lists.php.net
References: <20160525215208.034FC1A801B3@dd1730.kasserver.com>
 <e194be7d-2d72-945c-b8de-245e91f6f239@thefsb.org>
 <CAO3MkaD==1jQvS_cRbDrBQ7nkoBvoAaavmgxeMiP0mSKXL7eRQ@mail.gmail.com>
 <D36C9366.6E7CA%fsb@thefsb.org>
 <5fd54aa0-4fdf-c1e7-eae8-765aa89c8498@fleshgrinder.com>
 <cb4f05df-c5fa-68db-453a-274d42c2c15e@gmail.com>
 <08963b03-8394-6d62-4e5b-393f3fcb5647@fleshgrinder.com>
 <9e9db70d-d72d-d93e-0c81-18c2aa228618@gmail.com>
 <409002d8-b5e3-5990-7358-246adc7e3cab@fleshgrinder.com>
 <57474A08.80807@lsces.co.uk>
 <6f7403b6-bf22-a12b-dfb2-43fe82983e7d@fleshgrinder.com>
 <57474F9C.6080104@lsces.co.uk>
 <1733cfce-001b-1079-e929-88f7dde0f2dd@gmail.com>
 <57475F27.3090306@lsces.co.uk>
To: Lester Caine <lester@lsces.co.uk>, internals@lists.php.net
Message-ID: <50f5d1c9-d24f-1afe-4c34-70aafd981524@fleshgrinder.com>
Date: Thu, 26 May 2016 22:52:37 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <57475F27.3090306@lsces.co.uk>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="6vVTILv75xd4QDRcD4ih9I958FCHRoHsC"
Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties
From: php@fleshgrinder.com (Fleshgrinder)

--6vVTILv75xd4QDRcD4ih9I958FCHRoHsC
Content-Type: multipart/mixed; boundary="PJnR21SamRBPUGx458sKnGo6RDBARKE6c"
From: Fleshgrinder <php@fleshgrinder.com>
Reply-To: internals@lists.php.net
To: Lester Caine <lester@lsces.co.uk>, internals@lists.php.net
Message-ID: <50f5d1c9-d24f-1afe-4c34-70aafd981524@fleshgrinder.com>
Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties
References: <20160525215208.034FC1A801B3@dd1730.kasserver.com>
 <e194be7d-2d72-945c-b8de-245e91f6f239@thefsb.org>
 <CAO3MkaD==1jQvS_cRbDrBQ7nkoBvoAaavmgxeMiP0mSKXL7eRQ@mail.gmail.com>
 <D36C9366.6E7CA%fsb@thefsb.org>
 <5fd54aa0-4fdf-c1e7-eae8-765aa89c8498@fleshgrinder.com>
 <cb4f05df-c5fa-68db-453a-274d42c2c15e@gmail.com>
 <08963b03-8394-6d62-4e5b-393f3fcb5647@fleshgrinder.com>
 <9e9db70d-d72d-d93e-0c81-18c2aa228618@gmail.com>
 <409002d8-b5e3-5990-7358-246adc7e3cab@fleshgrinder.com>
 <57474A08.80807@lsces.co.uk>
 <6f7403b6-bf22-a12b-dfb2-43fe82983e7d@fleshgrinder.com>
 <57474F9C.6080104@lsces.co.uk>
 <1733cfce-001b-1079-e929-88f7dde0f2dd@gmail.com>
 <57475F27.3090306@lsces.co.uk>
In-Reply-To: <57475F27.3090306@lsces.co.uk>

--PJnR21SamRBPUGx458sKnGo6RDBARKE6c
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 5/26/2016 10:40 PM, Lester Caine wrote:
> I think what is irritating here is that actually both of these can stil=
l
> validly be null. It's HAVING to add the ? to every item when actually b=
y
> conventions 'NOT NULL' is the exception. Would ? indicating 'NOT NULL'
> actually be better since it IS only adding that flag which is required
> here to block the use of null?
>=20

The use case for the majority is the opposite. Java decided to go for
the /everything can be null/ and people are making jokes about it all
the time.

On 5/26/2016 10:40 PM, Lester Caine wrote:
> BUT DateTime currently will not store 'null' - it returns 'now' instead=
=2E
> We end up having to store string or integer values because we can't
> store a null date :(
>=20

This is unrelated to typed properties. You can implement your own
DateTime class that has support for your special use case.

On 5/26/2016 10:40 PM, Lester Caine wrote:
> The suggestion I was seeing was that a 'NOT NULL' value had to be
> initialized. I think my problem is perhaps is just what errors are
> created that break the normal flow and what gets returned when checking=

> to see IF a value has been initialised.
>=20

Nothing breaks your normal flow, you will be able to use isset() and
empty() as you always were.

On 5/26/2016 10:40 PM, Lester Caine wrote:
> $me->numSiblings would actually be null in this case if it has not yet
> been established since the answer may well be '0' but that just explain=
s
> why null is still valid even for an int property. We just have no idea
> if it's null because it's just been created or because the database rea=
d
> returned 'null'.
>=20

0 !=3D=3D null and if your database can return null for this field add it=
 to
its definition: `public ?int $num_siblings`

On 5/26/2016 10:40 PM, Lester Caine wrote:
> The alternate 'not null' value is more clear cut in that 'null' can mea=
n
> that it is uninitialized, and one needs to run the initialization code
> for it. I need is_null($me->numSiblings) to work and return true so I
> can select the initialization code, or should there be a new state of
> 'uninit' as well? Then if we want to 'reset' the person object do the
> 'not null' entries get rest to null so they can be re-initialized.
> 'unset' the person does not remove the object simply rewinds it to an
> unset state ... so should unset of these typed properties do that or do=

> we actually need an uninit?
>=20

Not null would result in the same questions being raised as we are
facing them now.

You can use !isset() instead of is_null(), it does the same thing
without errors being raised.

The concept of reseting objects and reinitializing them is something I
read very often from you. This is against all of OOP. What you are
basically doing is misusing classes as behaviorless anemic containers of
data. Even Smalltalk from the '70s did not encourage this and PHP never
did so either. Just because it is possible does not mean that it is the
proper way. Just make a new instance. ;)

--=20
Richard "Fleshgrinder" Fussenegger


--PJnR21SamRBPUGx458sKnGo6RDBARKE6c--

--6vVTILv75xd4QDRcD4ih9I958FCHRoHsC
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

iQIcBAEBCAAGBQJXR2IaAAoJEOKkKcqFPVVrO3YP/jQFEavz9jc08OECkqAganYm
BSMNgmkrXjkVYc4jWuzMZjdwNJZT8ZPlxFivgEUDaTkAY9Cv0gSAZ3i+O3E6IxJv
A9iriN+mSgpfSx1+AvfICJX6vda+hnnYVQQqKjVqr+9ftV+Z4aP7U9aMqtEJFpTN
2D+p+Mageb2A7MObfFeU1ukvOkrk1m2ep1lezWTggoRWpGyp1kyDos7J7Tj65/yv
iWrIOAVHDnxFm3i2SrTqMZSJCvPPf5ac7NUoRnAkXcyI517SfdFlkOykpg9SzdV8
V2mJreC6zYWmErTO7tBDi3sVeuaxHInjsjMu8j3NpXZR0vzO/ykWO+XYHDscmjwK
sAtqv2jT1sV8Eg1uKWdp/6Dr4unEAd3idA+/tUlL3Oaz5wHkylkFrXsoE9diS4yc
5m0Hv8boBG+yZu+/56bhJNmGI9pQnduEJuccKhez2xo50kae/E3lrrlT5A9eLIvs
zTLu5l16qRtDfTVutVQltvsuvxzX0UK8LZQoIwLq6L754simQDrOwY1kcGK8TH0B
UwZ3I+8+RowOymdhY3P88T33gNLJ2bIqtfl5e7puTpTiqGIGfpVwS8cwcpHKTfVX
ATeq05WZVu+RpD9Z64f0BzXvkEQrwUwUgtJ2Grs974CUiPgsPSCY7LaSBAymfd56
a84MMZKxEtspQFwjy6DJ
=Sn7r
-----END PGP SIGNATURE-----

--6vVTILv75xd4QDRcD4ih9I958FCHRoHsC--