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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
