On 17/09/2015 22:31, Lester Caine wrote:
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.
EG Vehicle is not old enough to need MOT
b) If you want this object, you may create a default one.
EG No current MOT found
c) If you want this object, create it with these parameters.
EG Display date of MOT ... when next one due should not be stored here,
only when one is added.
This is an entirely arbitrary mapping. You actually have two pieces of
information you're trying to fit into one variable:
- the MOT status, out of "not needed", "no current MOT", "has current MOT"
- the details of the current MOT, if one exists
That's what I was getting at with my "variable colours" example - if all
you're after is "a variable with 3 states, one of which also allows a
value", that's not really anything to do with exists() and isset() any
more. It would be a convenient use of that state, except that that state
isn't convenient to use, so why try?
This is also a perfect example of why co-opting states like null and
unset for complex meanings is generally a bad idea: what if in future,
you need to distinguish a 4th case of "never had an MOT"? You've now
used up both NULL and !exists(), so you're back to square one, and need
to petition for some other piece of variable metadata to be exposed - or
give up and change the implementation to use a separate state flag.
You then want to use null for case (b), so need a "very null" value
(non-existent variable) for case (a).
Database takes care of managing the business logic to ensure data is
consistent. One could use an invalid date for 'NULL' but these are not
consistent between database engines ... NULL is. Reading CAR data does
not return an 'MOT' record while it is not needed. 'MOT' does not exist
flags logic to display 'first MOT due' from registration date. Putting a
date in the 'MOT' field is not the way to handle that.
The business logic in decent databases like Oracle and Firebird rely on
NULL for many reasons, and while one can return more fields to handle
the 'three state' model, NOT returning a field is faster. MOT is crude
example, on council systems several sets of data may interact, and the
NULL state is significant.
You keep defending your use of NULL, but that is not what needs
defending; it is the proposed use of an unset variable as a "very null"
state which I am questioning. As far as I know, most databases do not
have the notion of "does not exist" in tables or result sets - the
result of a Left Join failing is the same type of Null as can be stored
in a Nullable column.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
