On 18/04/16 17:57, Larry Garfield wrote: > On 4/18/16 3:00 AM, Lester Caine wrote: >> On 18/04/16 04:56, Larry Garfield wrote: >>> 2) Doesn't make it quite so easy, which hopefully discourages (but does >>> not prohibit) its usage. >> This implies that using 'null' is wrong ... and is a slippery slope to >> then 'disabling' null where some people think it should be removed. If >> PHP development is making these sort of decisions it should be clear >> that is the intention, not just 'hopefully discourages' things that some >> people have no appreciation of the usefulness of! > > I am not sure what you're implying by "some people have no appreciation > of the usefulness of"... I am well aware of NULL's use cases. I am also > well aware that the general zeitgeist in the language development > community is that they're dangerous; the designer of the first language > to have them calls them a "billion dollar mistake", many languages > actively avoid having NULL in favor of something deliberately more > structured. NULLs are a very common cause of avoidable fatal errors in > many languages (including PHP). NULLs are rude to users of your API, as > it balloons the error handling code they need to deal with.
With a properly structured code flow, NULL is the ONLY logical solution to elements of the data that do not physically exist. And in my book that includes where we run out of whole records when running that work flow. PHP is a scripting language that works well with these flows of data, and NULL is certainly NOT a mistake IN that workflow. So in order to remove NULL you need to come up with a reason why the SQL standard is wrong and produce a new specification that can replace it ... and 'exception' is just another mistake that needs eliminating where that is not appropriate when a simple NULL currently does the job more than adequately. > I am on record and will continue to be on record that null is *usually* > wrong. I consider that position entirely justified, as does the > academic CS community. I am also now on record suggesting that we use > union types to allow type-or-null returns/parameters, which you're > welcome to quote me on. :-) > > Are you comfortable with the compromise position I've proposed? As long as I can simply wipe any use of ANY of this type code overload from my libraries and keep it out of ANY of the code PHP functionality it so that the database extensions still handle 'null' exactly as it is designed to work then that is all I need. I don't see ANY need to add internally the very code you are complaining we need to add externally removing the simple flexibility that provides. So I don't see the need for any compromise ... just scrap the whole waste of time adding unnecessary code and documenting why you think PHP is currently so broken ... -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
