Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:105159 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 60751 invoked from network); 9 Apr 2019 11:29:29 -0000 Received: from unknown (HELO mail4.serversure.net) (185.153.204.203) by pb1.pair.com with SMTP; 9 Apr 2019 11:29:29 -0000 Received: (qmail 30545 invoked by uid 89); 9 Apr 2019 08:26:19 -0000 Received: by simscan 1.3.1 ppid: 30539, pid: 30542, t: 0.0634s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.7?) (lester@lsces.co.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 9 Apr 2019 08:26:19 -0000 To: internals@lists.php.net References: Message-ID: Date: Tue, 9 Apr 2019 09:26:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Nullable Casting From: lester@lsces.co.uk (Lester Caine) On 09/04/2019 08:32, Guilliam Xavier wrote: >> I do kind of like the idea in the RFC, but I think it needs a better >> argument for it. > For your other points, I find that Claude Pache has given pretty good > arguments in the meantime (thanks!) =) (By the way, I also thought > about say, "nullable_intval()", "nullable_strval()" etc. but we're > missing "arrayval()" and "objectval()"...) The debate as always is between those for who 'NULL' is a key STATE that is part of the interaction between a database and program and those who do not have that need. In my world a variable has a number of states and NULL is simply one of them. Thinking of NULL as 'uninitialized' is a reasonable match, and when pushing a variable to a database it's NULL state can be used to trigger loading a default value or to leave the field unset for later handling. HAVING to put a value or a string into the variable because 'it must have a type' is simply wrong. But the need now to HAVE to cast at times is equally wrong? I'm still hitting errors in stuff being moved to 7.2 where the 'fix' is adding a cast, to keep PHP happy, but then the value may well be a NULL return from the data set so one almost ends up needing two versions of a variable ... one to keep the now stricter typing happy and one to store the actual data returned from the database. This also links up with the leading and trailing spaces discussion. That the working value is a left justified or right justified number but the logic now requires an 'int' to keep it quiet is pushing towards needing these separate versions of essentially the same variable :( Making the associative array view of the data difficult to manage ... -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk