Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88287
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.182 as permitted sender)
To: Lester Caine <lester@lsces.co.uk>, internals@lists.php.net
References: <CAKws9z27kVJ87Ur5Qo+ayYHPeeO=aYKpRHUV4TFBXX2iMcgO2A@mail.gmail.com>
 <55E6EC36.6090301@gmail.com>
 <E1C02A1A-EB7C-40D9-8760-13627CC7BF85@craigfrancis.co.uk>
 <9AF329EC-99A5-412D-A52B-432627A5520F@gmail.com>
 <6F4D91EE-B56E-4B83-B1AF-598C3F6897FC@craigfrancis.co.uk>
 <55F07BA4.2000204@gmail.com>
 <E8634CF1-C2B4-4C5A-8DDC-531D9599774B@craigfrancis.co.uk>
 <55F6B911.9080400@gmail.com>
 <96BE7F01-D04B-483B-B1A3-B45CED6DFCDC@craigfrancis.co.uk>
 <55F6F08C.1020506@gmail.com>
 <0BEF6D82-CB5F-49F6-A3A4-3267924A0CDA@thesba.com>
 <55F72CA9.2060301@gmail.com>
 <09369945-76FE-4E08-9C2C-15FB0577AD27@thesba.com>
 <55F752E7.9070801@gmail.com>
 <D062C4F7-B56E-422F-A563-C7C4A16D36B0@thesba.com>
 <55F9B4C7.3050700@gmail.com>
 <440C64A2-4B4F-4AEF-ACE3-F3A6637EBAB6@thesba.com>
 <55F9D704.5050002@lsces.co.uk>
 <FD9ABCC5-E928-4810-AE1A-E1DC7E0FB3D1@gmail.com>
 <55F9EFA2.9020908@lsces.co.uk>
 <0022A1D9-DC37-4F49-B58E-FBED5AF872BA@gmail.com>
 <55F9FAB3.2050100@lsces.co.uk>
Message-ID: <55FB19CB.7080707@gmail.com>
Date: Thu, 17 Sep 2015 20:51:39 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <55F9FAB3.2050100@lsces.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?
From: rowan.collins@gmail.com (Rowan Collins)

Lester Caine wrote on 17/09/2015 00:26:
> If the 'variable' exists but is NULL you create a default element of
> that name. If the 'variable' does not exist nothing gets created. So
>
> exists($checklist) {
>    is_null($checklist) { create default/empty object(); }
>    else { create populate odbject($checklist);
> } else {
>    display code in place of object;
> }

Thanks, this is an interesting example of how the function could be used.

To paraphrase, your 3 states being communicated from the controller to 
the view are:
a) Do not use this object, even if you want to.
b) If you want this object, you may create a default one.
c) If you want this object, create it with these parameters.

You then want to use null for case (b), so need a "very null" value 
(non-existent variable) for case (a).

I think I would personally find it more readable if null was reserved 
for case (a), which feels closer to the normal meaning of NULL as 
"missing data", like in a database. Some other terminal value would then 
need to be found for case (b) - a string like '__DEFAULT__', for 
instance (if $checklist is normally an integer, literally any string 
will do; if it's normally a string, you've got to be more careful with 
your choice of reserved word).

Or, I might architect it in a completely different way, and pass around 
an object that can lazy load its own data, rather than lazy loading the 
object itself based on a scalar value. But I can't say that the proposed 
approach is "wrong", exactly.

If you're so eager to do this that you'd be willing to make the 
application have a minimum PHP version of 7.1, I suppose it's an 
argument in favour of changing the language to allow that. But since 
there are plenty of alternative ways to architect this in the current 
language, it seems slightly artificial.

As a straw man example, if the language allowed me to assign colours 
(with a 'u', in the spelling, because I'm British :P) as metadata to a 
variable, I could write it like this:

switch ( get_colour($checklist) ) {
     case COLOUR_RED:
     default:
         // display code in place of object;
     break;
     case  COLOUR_YELLOW:
         // create default object
     break;
     case COLOUR_GREEN:
         create_object($checklist);
     break;
}

Obviously, that's a stupid idea, but in a sense that's what you're 
actually asking for - a piece of metadata about the "state" of the 
variable, alongside its value; it just so happens that there's a 
candidate piece of metadata that would be fairly easy for the language 
to give you. With null vs non-null, you have two states, with exists() 
you could distinguish a third state - but that third state doesn't 
really have anything to do with non-existence, it's just an extra piece 
of information that the controller wants to pass to the view.

What would really be handy in a case like this is the ability to create 
your own null-like values, guaranteed to be distinct from all other values:

type hidden extends \php\basetypes\terminal {}
type default extends \php\basetypes\terminal {}

$checklist = hidden;
gettype($checklist); // 'hidden'
$checklist == hidden; // true
$checklist == deafult; // false
isset($checklist); // true

Maybe even:

type missing extends \php\basetypes\null {}
$foo = missing;
isset($foo); // false
is_null($foo); // not sure...


Regards,
-- 
Rowan Collins
[IMSoP]