Re: [RFC Discussion] Typed Properties

On Wed, Mar 16, 2016 at 6:17 PM, Andrey Andreev <narf@devilix.net> wrote: > 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. Not sure what you're saying there Andrey. > That's fine. Type checking doesn't say that a value is correct or meaningful; it > just enforces the shape of the data. > Larry Solid points! Exactly that. A type relevant default of 0 is not definitively invalid, it's up to application logic to work that out. 0 is totally valid as an integer. I do quite like the idea of type relevant defaults being provided, so 0, [], "", etc, just like Go. The only trouble I see there is: what sane default is given for public Foo $foo;? Instantiate the class? Erf.