On Thu, Mar 17, 2016 at 12:00 AM, Larry Garfield <la...@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.
