On 5/26/2016 10:40 PM, Lester Caine wrote: > I think what is irritating here is that actually both of these can still > validly be null. It's HAVING to add the ? to every item when actually by > 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? >
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. > We end up having to store string or integer values because we can't > store a null date :( > 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. > 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 explains > 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 read > returned 'null'. > 0 !== 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 mean > 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? > 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. ;) -- Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
