On 05/04/2019 14:05, Robert Hickman wrote:
I think you're misunderstanding the problem: it's not that the*programmer*  
doesn't know the types, it's that the*analysis tool*  doesn't know them, 
because the programmer hasn't told it, and currently has no way to tell it.

If the static analyser was programmable, it would be possible to
provide it such information, within the scope of a single code base.

In the case of data returned from a database, the metadata for the database is another source of information relating to that data, and it would be useful if PHP had a means to access that data, but in reality this is still currently an area for developing 'a single code base' within the IDE level rather than PHP itself?

The question in my mind is if there is still a place for results sets returned by a database query to simply be associative array elements or whether this is now too old fashioned and each should be an object which handle the validation functions relating to it and encapsulated in an object managing the various aspects of the query results such as errors returned and the like. In place of returning 'false' when something failed? Somewhere to hang failed returns rather than simply throwing the error in the hope that something else will deal with it?

--
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to