Lester Caine wrote on 18/09/2015 01:32:
On 18/09/15 00:14, Rowan Collins wrote:
I'm confused - do you mean that some rows in the result set from the
database have columns "missing", rather than just set to NULL? That's
not something I've ever come across before.
While it would be better SQL practice to list all fields used in the
result set, '*' will return 'all fields' which are visible and may
indeed have 'missing fields'.
Whether or not you use "Select *", all the rows in the result set have
the same number of columns, surely?
By the way, you still haven't addressed my point about this whole setup
only giving you 3 states, and there being no particular reason you won't
need a 4th later.
For this particular method of working which is perhaps 20 years old,
there are only three states. If the field exists in the result set, if
it's null and if it has a value.
Sure. I was thinking more that your example mapped those 3 states rather
arbitrarily onto 3 domain states that you wanted to model; if you
happened to want to model 4 states, this technique wouldn't be any help.
Currently one has to switch off errors where is_null may be used with a
non-existent field
Why? That's what isset() is for, which is where this whole discussion
started; I'm not sure why you've suddenly mentioned is_null().
But the whole problem here is that isset does NOT identify that the
result set has fields that are NULL.
My point was that if you use isset() in place of is_null(), you don't
have to switch off any errors. That's the only difference between the
two functions - that isset() doesn't raise a notice if the variable
doesn't exist.
Deprecate expand() so it's use is not possible may be another 'fix'?
Surely there are plenty of ways to use extract() without attempting to
give meaning to missing variables.
So similarly there are plenty of ways of using null field variables if
extract() has created them.
Huh? All I meant was, asking to deprecate extract() is like saying "I
can't use an object as an array key, so we might as well get rid of
associative arrays" - just because you can't use it in the way you'd
like, doesn't mean it's useless.
(That said, I'd personally be happy to see PHP lose extract(), and
variable-variables, and the $GLOBALS array - but it's pretty unlikely.)
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
