Как стать автором
Обновить
38
0
LoneCat @LoneCat

Пользователь

Отправить сообщение
Отписался по поводу скаляров выше: habrahabr.ru/blogs/php/136835/?reply_to=4554710#comment_4554800
Ну если программист хороший — то почему нет, ради действительно хорошего программиста не жалко будет и кодовые соглашения переписать :)
В общем не найти мне статьи где это подробно расписано, вот вам простейший тест:
// Начальная переменная со строкой в 1000 символов
$a0 = str_repeat('*', 1000);

// Создаем 1000 переменных
extract(range(1, 1000), EXTR_OVERWRITE, 'a');

// Исходное потребление памяти
echo memory_get_usage() . '<br />';

// Копируем по значению
for($i = 1; $i < 1000; $i++) {
	${'a' . $i} = $a0;
}

// Память остается прежней
echo memory_get_usage() . '<br />';

// Создаем ту-же строку с нуля
for($i = 1; $i < 1000; $i++) {
	${'a' . $i} = str_repeat('*', 1000);
}

// Потребление памяти увеличивается в разы
echo memory_get_usage() . '<br />';
В C вроде как каждый блок {} имеет свою область видимости, то есть если объявить переменную прямо внутри цикла — то она заменит собой переменную объявленную извне, но только внутри цикла.
Эм… ну я даже затрудняюсь ответить… по назначению? :)
Почему, это в первую очередь к скалярным типам и относится, ну и к массивам, а объекты всегда передаются по ссылке, они с copy on write никак не связаны, при наличии двух ссылок на объект и изменении объекта в одной — копия создана не будет.
Тут про «copy on write», значение (в нутрях php, в zend engine), копирует только когда это действительно необходимо, иже когда оно изменяется, а так если иметь 10к переменных с одинаковым значением (скопировав их с какого-то одного) — память будет потребляться только на сами структуры переменных. И в мане кстати все ок, в мане про это знают :)
Так-то оно так, но в этом конкретном примере — нет резона использовать foreach по ссылке если не нужно изменять переменную.
$yaPeremenko, $yaObyekteg, $yaMassivcheg…
Активный словарный запас — это сколько человек использует слов в устной/письменной речи, с общим количеством известных ему слов это никак не связано.
Так это по-моему единственное понимание умысла, законом-то рассматривается умысел конкретно на убийство и вред здоровью, если был умысел убить, то очевидно что утюг брошенный в окно брошен туда специально. А если умысла не было, то мало толку знать на счёт бросившего — просто он дурак или дурак с феерической координацией, что утюги из его рук улетают в окно, в любом случае это убийство по неосторожности.
Навеяло: «учите match-часть» :)
Мда…
У автообновления есть ввод выбора пользователя «да, жги!» и «не, потом»? — Это контроллер.
У автообновления соот-но наверняка есть окно где этот выбор реализован в виде пары кнопок, прогрессбара и т.п.
— это представление.
А версионирование, хранение файлов и т.п. бизнес-логика автообновления — это модель.
Почему целое должно умещаться в треть и зачем его туда пихать — вот вот это уже интересный вопрос.
А также call_user_func(любой объект с методом __invoke, включая Closure).
Нет, вы что, издеваетесь, а call_user_func($v) — здесь вам понятно функция это или объект?
$v('test') — это функция, всегда, объектом может быть только new $v('test'), чтобы у объекта работал $v('test') у него должен быть метод __invoke, который, о чудо, заставляет объект эмулировать функцию. call_user_function нужен если есть нужда вызывать методы объектов в виде array($object, 'method'), но и накладные расходы при вызове у него больше, так как это функция, а variable functions — языковая конструкция.
SQL injection до сих пор и существует из-за того что кто-то просто «нормально» пишет запросы, достаточно один раз ошибиться чтобы он был, и достаточно один раз написать экранирующую обертку чтобы его не было никогда, тем более что большинство современных SQL РСУБД поддерживают prepared statements, где данные не нужно писать напрямую в запрос.
С одной стороны яростно плюсую — действительно одна из вещей которые забывают в применении исключений — то что их еще нужно ловить, с другой стороны не понятно что конкретно вы имеете в виду, перехватывать нужно известные коду исключения, если объект формы работает с тремя типами объектов — валидаторы, декораторы, фильтры — то и ловить он должен соот-щие три типа исключения, если вдруг к нему проскочит исключение работы с БД — оно как раз должно провалиться насквозь, так как объект к БД не обращался — и оно пришло из вышеописанных трех типов объектов, которые в идеале, раз уж работают с БД (хотя с чего-бы это им приспичило) и должны были его отлавливать и оборачивать в собственное исключение, о чем и будет проинформирован программист когда исключение провалится до верхнего уровня.
Так а с тем что я написал это как связано? try/catch верхнего уровня с выводом «Пичалька» на экран и есть обработка исключения, и известно как его обработать — вывести ошибку, фронтальный контроллера зенда именно этим занимается.
Он и изобретение резиновой верстки приписывает себе, хотя html-страница без указанных жесткий размеров как-бы, ну я даже не знаю как это прямо сказать, из коробки резиновая :)

Информация

В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Дата рождения
Зарегистрирован
Активность