Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91719
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.218.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <56E9D787.8070705@garfieldtech.com>
References: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>
	<56E9AAF1.7070200@garfieldtech.com>
	<CAObuZdtbvdUvMnDTrkAWZtzOYeK48-TDiOQ3UVNo6oVRKYhe0Q@mail.gmail.com>
	<CAPhkiZwMC66VE5=8_Zs7CA+W8UmGjRMv7t8aJnVCMpyA4sdDiQ@mail.gmail.com>
	<56E9D787.8070705@garfieldtech.com>
Date: Thu, 17 Mar 2016 00:17:01 +0200
Message-ID: <CAPhkiZyHH1hHr0gyDVyNW=EM8j-B5-dfXJRzhFhxi2D7DaNMSg@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114087aa815273052e31df1c
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
From: narf@devilix.net (Andrey Andreev)

--001a114087aa815273052e31df1c
Content-Type: text/plain; charset=UTF-8

On Thu, Mar 17, 2016 at 12:00 AM, Larry Garfield <larry@garfieldtech.com>
wrote:

> On 3/16/16 2:30 PM, Andrey Andreev wrote:
>
>> Also, a LOT of code would end up with e.g. a default value of 0 for an
>> integer property, still having to check if it was properly populated with a
>> positive value - not much of an improvement over NULLs. Cheers, Andrey.
>>
>
> That's fine.  Type checking doesn't say that a value is correct or
> meaningful; it just enforces the shape of the data.
>
> Vis, type enforcement tells you that the property is an integer; it
> doesn't tell you that the integer is within the range of legal values for
> the temperature of a room.  It tells you that a property is a string; it
> doesn't tell you that the string doesn't contain NSFW words.  Those are all
> application-level concerns, not type-level concerns, no matter what we do
> here.  (Just like they are for parameters and returns already.)
>
> IMO, int/string/float is only a big deal on properties if you're using
> reflection for DB schema generation or similar, as it lets you remove an
> annotation.  (That's a useful benefit, though.)  The bigger impact for me
> is for class names, so I can enforce a given object type on a certain
> property.  Knowing "at least it's not NULL" has a much larger benefit in
> that case, as you avoid many "method called on non-object 100 execution
> lines later than the actual bug, good luck finding it" errors. :-)


Yet, your argument was about avoiding is_null() calls within application
logic and you'd gain nothing if you end up having to write ! empty()
instead. :)
I'd rather have a NULL to tell me that I have nothing instead of a
supposedly initialized but otherwise invalid value.

Cheers,
Andrey.

--001a114087aa815273052e31df1c--