Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91774
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 212.232.28.124 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>
 <56ED28BD.4040900@fleshgrinder.com> <56ED2FCB.6030609@lsces.co.uk>
 <56ED31BD.50307@fleshgrinder.com> <56ED36A6.4090201@lsces.co.uk>
To: internals@lists.php.net
Message-ID: <56ED4363.8030908@fleshgrinder.com>
Date: Sat, 19 Mar 2016 13:17:39 +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: <56ED36A6.4090201@lsces.co.uk>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="c10wXUi8xNSd40feXW00X68OI5eCsAd8b"
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
From: php@fleshgrinder.com (Fleshgrinder)

--c10wXUi8xNSd40feXW00X68OI5eCsAd8b
Content-Type: multipart/mixed; boundary="kVFmniMoW9BqHJAc1S2BtmxxDHBRQTAt8"
From: Fleshgrinder <php@fleshgrinder.com>
Reply-To: internals@lists.php.net
To: internals@lists.php.net
Message-ID: <56ED4363.8030908@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>
 <56ED28BD.4040900@fleshgrinder.com> <56ED2FCB.6030609@lsces.co.uk>
 <56ED31BD.50307@fleshgrinder.com> <56ED36A6.4090201@lsces.co.uk>
In-Reply-To: <56ED36A6.4090201@lsces.co.uk>

--kVFmniMoW9BqHJAc1S2BtmxxDHBRQTAt8
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 3/19/2016 12:23 PM, Lester Caine wrote:
> On 19/03/16 11:02, Fleshgrinder wrote:
>>>> Properties need the ability to be void even after construction and i=
t is
>>>>>> up to the object to keep track and ensure state. Nullability is im=
ho not
>>>>>> necessary at all. So we are all in line here.
>>>>
>>>> If the record I am working with identifies elements are incorrectly
>>>> matched, then making a value 'void' is the correct action. We would =
just
>>>> NULL that identifier and fire off a delete to the linked record in t=
he
>>>> database. Otherwise we have to create additional logic to handle tha=
t.
>>>>
>> And *void* would translate to *unset($record->property)* and not to
>> *$record->property =3D null*. This works with the current implementati=
on
>> and any *isset($record->property)* works too. As you can see,
>> nullability was not required. :)
>=20
> I did not say what we have now is actually right ... NULL state is
> simply a mess :)
>=20
> I need '$record->propertyX =3D null' because the property is part of th=
e
> data model. Unsetting propertyX so it does not exist means I have to
> recreate it if I want to add it again, BUT if I am reading a new record=

> from the database I need a variable to put the propertyX into even if
> that element of the result array is 'NULL'.
>=20
> Going back to 'basics', I have an array of fields ( and using ADOdb
> rather than PDO I have accurate data on what each field is! ).
> Initializing the object view of that record I scan each field value and=

> validate the data, or skip it if the field is NULL. Do I need a
> propertyX if it has no value - in my book yes - so that when building
> the template to display the data I can include that this does not exist=
=2E
> Could I use 'isset' instead - no - because THAT state says leave out th=
e
> field from the data display altogether. Could I create some arbitrary
> default value that is 'not set' ... yes, but that is not how the years
> of code base has been built! NULL is 'value not set' not 'this variable=

> does not exist'
>=20

You are mixing to things like I did. If you never unset and never assign
then the value of the property is *null* or as I defined to avoid
confusion *void*. All fine. The question was, should this result in an
error and the general consensus here is /no/.

The thingy with *unset* would be during runtime for whatever dubious
reasons.

--=20
Richard "Fleshgrinder" Fussenegger


--kVFmniMoW9BqHJAc1S2BtmxxDHBRQTAt8--

--c10wXUi8xNSd40feXW00X68OI5eCsAd8b
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

iQIcBAEBCAAGBQJW7UNnAAoJEOKkKcqFPVVr0gQP/i+7TEDQslm9HITP/a7sXiLM
lvnw8mHefzRvGRZOHBuPqDTRZpcGK48CiRNYyd5eDozIaUP5WEFfcSha+EpT14c7
eVcca9AOM9sdsSY+Wlw+vOqdMzuqrRua4v6HyJCTaJx9hLrTeyk1qgJ5lvacg4KX
xajMtjXf3ujd/0sBAI0mUPbGa38qyJKYUjXJLRvdGxzOxGoig84H+m5tVZMvgsy/
ewk77C242acOP7XrCSOoS6vZMaOgJj0La0rOWMjkpQ/kSWmlOyQXtkm7dzt89YQT
CWu0iAwahuJXJZkEwgkWY7OKnYDX0WyA79KX9bo+gmEZRtPgC0nXDcWyOiy7Jikg
/Pg1DUptbcLArfRJ/lYi+Q2sWLtg/+zFUd7V5XHvqPetftJlztMEr8xSvd7/gCGv
w2uIKA8sxv+rcSKs4t+DCCwhKOZHHPnXa7cCCdAYh3JJ5iIa34Js1vRvlaok+tlv
Zg/Ylz935VrGDoBxRYnMHgSS9stkGv7BMyQ7p2PDnzJAEeCIFv0I3xpZAHlNaKlK
ZSDZrpzgI2S+pJJogWLjIkFYy8HatAoKXwVNNhpCsA9N+CQMEZ4QAGQMRa6wKVrG
shgXdDMI7teJiTQM2BfyjjOLDlVkHbjh+segF/vm1GBRMWbDKLPtO3C9mmMe+VuL
JNEU+rbWtPM0H2yJU3bC
=R0nz
-----END PGP SIGNATURE-----

--c10wXUi8xNSd40feXW00X68OI5eCsAd8b--