PHP и с чем его едят....

[ostapoff]

error_reporting(E_ALL | E_STRICT) делает PHP очень параноидальным. В PHP область видимости переменных ограничена текущей функцией и доступ в более высокий уровень отсутствует по-умолчанию (только через global или using). В perl-e все с точностью до наоборот, программист вынужден использовать my, чтобы локализовать область видимости.

 

[kattykatty_]

Как показывает прочтение статьи, trim не должна принимать null, но принимает, а по уму должна была бы ругаться.

Из ваших высказываний я сделала вывод, что реализация функции trim() в php такая, что передаваемые ей типы данных object, resource, array вызовут Warning и не прекратят исполнение скрипта, а integer, float, boolean и null будут приведены к типу string вам кажется не удачной.
А реализация trim(), при которой переданный ей любой тип данных, кроме string даст ошибку, корректной.
В связи с чем у меня к вам вопросы.
1. Правильно ли я поняла вашу мысль и если да, то не могли бы вы на примерах кода доказать, что вторая (более строгая) версия реализации trim удобней ?
2. Какую ошибку вы считаете должен выдавать php во второй реализации (warning, fatal error или др)?

 

[PainKiller]

error_reporting(E_ALL | E_STRICT) делает PHP очень параноидальным. В PHP область видимости переменных ограничена текущей функцией и доступ в более высокий уровень отсутствует по-умолчанию (только через global или using). В perl-e все с точностью до наоборот, программист вынужден использовать my, чтобы локализовать область видимости.

Это очевидно, НО, error_reporting(E_ALL), как понятно из самого названия функции, просто выводит больше, а нотис, как известно, за ошибку не считается. Я говорю про одно, а мне в ответ совершенно другие, очевидные вещи.
Заметьте, use strict не просто выводит ошибки, а не дает perl выполнить кривое поделие, аналог error_reporting в перле - -w или -W ключи запуска, к ним же, кстати, можно добавить проверку на загрязненность, но не суть.

 

[PainKiller]

Из ваших высказываний я сделала вывод, что реализация функции trim() в php такая, что передаваемые ей типы данных object, resource, array вызовут Warning и не прекратят исполнение скрипта, а integer, float, boolean и null будут приведены к типу string вам кажется не удачной.
А реализация trim(), при которой переданный ей любой тип данных, кроме string даст ошибку, корректной.
В связи с чем у меня к вам вопросы.
1. Правильно ли я поняла вашу мысль и если да, то не могли бы вы на примерах кода доказать, что вторая (более строгая) версия реализации trim удобней ?
2. Какую ошибку вы считаете должен выдавать php во второй реализации (warning, fatal error или др)?

Ок, вот для примера, реализация trim, как ее вижу я. Писать все лениво, если можно допилить условие:

<?php
error_reporting(E_ALL);
function _trim($str)
{
	if($str == '' || !isset($str))
	{
		trigger_error("first param must not be null or empty string", E_USER_NOTICE);
		//return null по желанию
	}
	else
		return trim($str);
}
function _trim2($str)
{
	if($str == '' || !isset($str))
		return null;
	else
		return trim($str);
	
}
echo '<pre>';
echo 'trim';
$str=trim(null);
var_dump($str);
echo '_trim';
$str2=_trim(null);
var_dump($str2);
echo '_trim2';
$str3=_trim2(null);
var_dump($str3);
echo '</pre>';

?>

Ну вот _trim - первый вариант
_trim2 - второй вариант. Это то, как я вижу их работу, это, так сказать, чтоб поточнее передать свою мысль.

Мне не нравится именно то, что оно из null делает строку, т.е. из ничего строку. Думаю, моя точка зрения ясна и она, кстати, не претендует на истину в первой инстанции.

 

[ostapoff]

E_NOTICE предупреждает девелопера о потенциальных ошибках, грязном коде, опечатках, плохом стиле и неинициализированных переменных в частности. must have для разработчика.

На счет trim – Вы пытаетесь языку навязать сильную типизацию. Это просто не PHP-way.

 

[dreamer]

Боже, а нафлудили…

 

[[fly]]

Подскажите пожалуйста. Есть вопрос. Допустим есть авторизация, где при успешном исходе, я присваиваю юзеру сессию ['user']. Так вот сам вопрос. Есть ли смысл для проверки писать следующее:

if (isset($_SESSION['user']) and $_SESSION['user']=="yes")

или достаточно будет написать простой проверки

if ($_SESSION['user']=="yes")

Интересуют все аспекты этого момента. Как со стороны оптимизации, логики ну и всего остального.

 

[ostapoff]

Имеет смысл писать всегда первый вариант. Если переменная сессии не будет установлена, то будет выдан notice. Можно конечно написать

if (@$_SESSION['user']=="yes")

чтобы подавить notice, но в этом случае PHP создаст дополнительный код для его перехвата. На производительности это практически скажется, если конечно, эта проверка не в цикле с десятком миллионов иттераций

 

[[fly]]

Ясно. Просто у меня без собачки не выдавало никаких нотисов. Но спасибо за ответ

 

[ostapoff]

Все зависит от конфигурации в php.ini или принудительной конфигурации используемого Вами фреймворка.
По-умолчанию в php.ini error_reporting устанавливается в E_ALL & ~E_NOTICE
по этому Вы их и не видите.

Рекомендуемый уровень ошибок для разработки в 5.3: E_ALL | E_STRICT
Для продакншн сервера: E_ALL & ~E_DEPRECATED