[TYPO3-core] RFC: minor optimisation of getRecordRaw()

[Dmitry Dulepov]

Hi!

Martin Kutschker wrote:
> In know. I didn't change that because the original code lacked the 
> check. In fact no TYPO3 code ever checks for a SQL result.

It has a nice side effect: if warnings are enabled, you always know when 
database is not ok :D

However if we favor code quality, we should do such checks in future. 
What do you think?

By the way, I had an idea to add a call to devLog to sql_fetch_assoc() 
function in case if passed $res is not valid. It could use 
debug_backtrace() (PHP>=4.3) to show who passed bad $res. Thus helps 
locating the problem much easier. While I had to put 
debug_print_backtrace() several times locally to discover problem 
origins, I never managed to make a good patch for it due to lack of time :)

> Fine with me, but we should define whether we want NULL (your 
> suggestion) or FALSE (usual PHP behaviour) for array returning functions.

I prefer "false". With "false" I can do this:

	if (false !== ($result = $obj->arrayReturningFunction())) {

which looks better (faster readable) to me than

	if (!is_null(($result = $obj->arrayReturningFunction())) {

Of course old good (typo3 style)

	if (($result = $obj->arrayReturningFunction())) {

will work in both cases but I do not like this C style much. It does not 
create easily readable code.

-- 
Dmitry Dulepov

Web: http://typo3bloke.net/
Skype: callto:liels_bugs

"It is our choices, that show what we truly are,
far more than our abilities." (A.P.W.B.D.)