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