Непонятно, что имеется в виду под заводским великом.
Если один из стардартных API — PDO или Mysqli, то это не велик, а набор запчастей «сделай сам». На них, конечно, можно ездить, но только на одной передаче и очень часто крутя педалями. И руль заклинен в положении «прямо».
Database access wrapper писать в любом случае нужно, с голым API жить невозможно.
Если имеются в виду DAL и квери-билдеры различных фреймворков, то это тоже не фабричные велосипеды. И я бы с удовольствием с ними погонялся.
Ой. В пыхе столько функций, что если использовать все — код писать будет некогда.
Есть реально удобные — http_build_query(), например.
Но когда функцию можно заменить простым циклом — я не вижу смысла вводить в код новую сущность.
Я лучше сам цикл заверну в функцию, и буду обращаться к ней. Это получится чище и понятнее, чем ваш анонимный уродец. Вы сами-то не видите разве, какой франкенштейн получился?
Я прекрасно понимаю программиста, которому хочется написать покороче. Но я, к сожалению, имею опыт не только написания, но и чтения кода. И я дам 10 тупых но читабельных копи-паст методов против одного завернутого хака с переподвыподвертом, экономящего аж две строчки кода.
Мне это утверждение видится несколько голословным.
Вы не могли бы привести хотя бы пару доводов в обоснование своей позиции?
А я пока приведу в защиту противоположной.
Во-первых, как уже здесь упоминалось, foreach нагляден, привычен и читабелен.
Во-вторых, foreach позволяет совершенно естественно реализовать логику фильтрации любой сложности. В то время как для array_filter в любом мало-мальски сложном случае придется писать отдельную функцию.
Лично я для себя нашел только одно удобное применение array_filter() — проверка на наличие непустых ячеек в в массиве:
if (!array_filter($arr)) {
echo "Все ячейки пустые!"
}
Ну, строго говоря, сандбокс — это очень ограниченная область применения (которую, собственно, и имел в виду первый комментатор), а остальное делается просто.
Пока из реальных проблем нейтива я столкнулся только с одной — автоискейпинг для свойств объектов. В то время как для скаляров и массивов он реализуется элементарно, для объектов это действительно — головная боль.
Вы просто отчаянную ерунду написали. Умудрились наделать ошибок практически в каждой строчке.
1. Шаблоны нужны не для редактирования пользователем, а для разделения бизнес-логики и логики отображения. Чтобы одни и те же данные можно было выводить в разном виде, не трогая код приложения. Пример: один и тот же движок стоит на разных сайтах. Если используется шаблонизация, то обновление движка сводится к простой заливке кода. Если шаблонизация не используется — под каждый сайт движок надо редактировать отдельно. ещё пример: одно и то же приложение может возвращать как HTML, так и JSON. Если для первого использовался шаблонизатор, то добавить второе можно не трогая код. В противном случае код придется переписывать (и дублировать).
2. В случае с Twig никакой бесполезной траты ресурсов нету — шаблон транслируется в тот же самый РНР код.
3. Приведённый пример РНР кода тоже вполне может быть шаблоном (что повсеместно и используется)
4. Мог бы быть, точнее. Но не является, из-за непонятной функции procedurename(), которая, если что-то выводит и реализована в коде приложения, убивает идею шаблонизации на корню.
Про чувствительность заднего места в тексте ничего не было.
Было только отладку уже случившейся ошибки на (предположитьельно) PDP-11 с 50-ю килобайтами памяти и соответствующим размером программ.
Ну, лично я — не Томпсон.
И построить в голове модель, учитывающую состояние всех классов на 10000 строк, сервера, входящих данных, среды и БД — просто не в состоянии.
Поэтому отлаживаться приходится неэффективными методами — трассировкой и чтением сообщений об ошибках.
Вы меняете контекст :)
Если бы информация была срочная, то я бы не стал обращать внимание на оформление.
Но статья с картинками про довольно банальный техпроцесс таковой не является. И нет ни одной причины делать с неё плохой перевод.
Проблема в том, что вы — не единственный сторонник этой «философии».
К сожалению, она приобретает всё больше поклонников, поскольку позволяет дилетантам ставить себя на одну доску с профессионалами, уравнивая знания с мнением. Очень хорошо говорит об этом профессор Зализняк в своих лекциях, поскольку ему часто приходится сталкиваться с её последствиями.
По поводу же «литературного кружка», перевод — это, как раз, литературная деятельность.
Да с какой стати «прав каждый»-то? Что за ерунда?
Не всё относительно. Не надо использовать эту фразу для оправдания любой глупости.
Тот, кто пишет «отверстия сверляться» — неправ.
Тот, кто считает, что «Хабр — для неграмотных людей» — тоже неправ. Поскольку в правилах написано обратное.
Есть простые и чёткие критерии, по которым можно определить истинность или ложность утверждения. Никакой относительности.
Пожалуйста, не пишите этой ерунды больше, и особенно — в «техническом блоге».
Если бы технические специалисты следовали этому «правилу», то самолеты бы не летали, а компьютеры горели бы пачками. «Ну и что, что трубопровод не по инструкции подсоединён! Всё относительно ведь, каждый прав по-своему».
Поощрение Хабром доморощенных переводчиков имеет и неприятную сторону — снижение стандартов языка.
Если раньше любой печатный текст всегда был не только грамматически, но и стилистически выверен, то сейчас мы легко можем увидеть такие перлы, как
«имел удовольствие удостоиться чести»
«процесс лежит на плечах городка»
«свёрел»
«изюменка»
-тся, -ться — тьфу.
Если бы это был единичный ляп — я бы написал в личку. Но, на мой взгляд, литературные и переводческие («rack» — набор?) достоинства статьи довольно низки. Автор явно поторопился выкладывать. Стоит познакомиться с девочкой-филологом и отдавать свои творения сначала на вычитку ей.
Мне кажется, не стоит до такой уж степени троллить собеседника.
Он, кстати, единственный, кто внятно написал про организацию пула, в отличие о того же lair'а, у которого только невнятные пассы руками про «случаи бывают разные» и ничего конкретного.
Если один из стардартных API — PDO или Mysqli, то это не велик, а набор запчастей «сделай сам». На них, конечно, можно ездить, но только на одной передаче и очень часто крутя педалями. И руль заклинен в положении «прямо».
Database access wrapper писать в любом случае нужно, с голым API жить невозможно.
Если имеются в виду DAL и квери-билдеры различных фреймворков, то это тоже не фабричные велосипеды. И я бы с удовольствием с ними погонялся.
Есть реально удобные — http_build_query(), например.
Но когда функцию можно заменить простым циклом — я не вижу смысла вводить в код новую сущность.
Я лучше сам цикл заверну в функцию, и буду обращаться к ней. Это получится чище и понятнее, чем ваш анонимный уродец. Вы сами-то не видите разве, какой франкенштейн получился?
Я прекрасно понимаю программиста, которому хочется написать покороче. Но я, к сожалению, имею опыт не только написания, но и чтения кода. И я дам 10 тупых но читабельных копи-паст методов против одного завернутого хака с переподвыподвертом, экономящего аж две строчки кода.
Вы не могли бы привести хотя бы пару доводов в обоснование своей позиции?
А я пока приведу в защиту противоположной.
Во-первых, как уже здесь упоминалось, foreach нагляден, привычен и читабелен.
Во-вторых, foreach позволяет совершенно естественно реализовать логику фильтрации любой сложности. В то время как для array_filter в любом мало-мальски сложном случае придется писать отдельную функцию.
Лично я для себя нашел только одно удобное применение array_filter() — проверка на наличие непустых ячеек в в массиве:
Пока из реальных проблем нейтива я столкнулся только с одной — автоискейпинг для свойств объектов. В то время как для скаляров и массивов он реализуется элементарно, для объектов это действительно — головная боль.
1. Шаблоны нужны не для редактирования пользователем, а для разделения бизнес-логики и логики отображения. Чтобы одни и те же данные можно было выводить в разном виде, не трогая код приложения. Пример: один и тот же движок стоит на разных сайтах. Если используется шаблонизация, то обновление движка сводится к простой заливке кода. Если шаблонизация не используется — под каждый сайт движок надо редактировать отдельно. ещё пример: одно и то же приложение может возвращать как HTML, так и JSON. Если для первого использовался шаблонизатор, то добавить второе можно не трогая код. В противном случае код придется переписывать (и дублировать).
2. В случае с Twig никакой бесполезной траты ресурсов нету — шаблон транслируется в тот же самый РНР код.
3. Приведённый пример РНР кода тоже вполне может быть шаблоном (что повсеместно и используется)
4. Мог бы быть, точнее. Но не является, из-за непонятной функции procedurename(), которая, если что-то выводит и реализована в коде приложения, убивает идею шаблонизации на корню.
5. Пост был совсем не об этом.
впрочем, далеко не копал, утверждать не возьмусь
www.thesun.co.uk/sol/homepage/showbiz/4517317/Bruce-Willis-to-fight-Apple-over-music-rights-after-his-death.html
Но вот утка это вряд ли.
Такое ощущение, что поддержкой своего кода заниматься не приходится никому.
Было только отладку уже случившейся ошибки на (предположитьельно) PDP-11 с 50-ю килобайтами памяти и соответствующим размером программ.
И построить в голове модель, учитывающую состояние всех классов на 10000 строк, сервера, входящих данных, среды и БД — просто не в состоянии.
Поэтому отлаживаться приходится неэффективными методами — трассировкой и чтением сообщений об ошибках.
Если бы информация была срочная, то я бы не стал обращать внимание на оформление.
Но статья с картинками про довольно банальный техпроцесс таковой не является. И нет ни одной причины делать с неё плохой перевод.
К сожалению, она приобретает всё больше поклонников, поскольку позволяет дилетантам ставить себя на одну доску с профессионалами, уравнивая знания с мнением. Очень хорошо говорит об этом профессор Зализняк в своих лекциях, поскольку ему часто приходится сталкиваться с её последствиями.
По поводу же «литературного кружка», перевод — это, как раз, литературная деятельность.
И снова в очередной success story ни слова об отладке.
То есть, программистом получившегося клепальщика кода назвать нельзя.
Не всё относительно. Не надо использовать эту фразу для оправдания любой глупости.
Тот, кто пишет «отверстия сверляться» — неправ.
Тот, кто считает, что «Хабр — для неграмотных людей» — тоже неправ. Поскольку в правилах написано обратное.
Есть простые и чёткие критерии, по которым можно определить истинность или ложность утверждения. Никакой относительности.
Пожалуйста, не пишите этой ерунды больше, и особенно — в «техническом блоге».
Если бы технические специалисты следовали этому «правилу», то самолеты бы не летали, а компьютеры горели бы пачками. «Ну и что, что трубопровод не по инструкции подсоединён! Всё относительно ведь, каждый прав по-своему».
Если раньше любой печатный текст всегда был не только грамматически, но и стилистически выверен, то сейчас мы легко можем увидеть такие перлы, как
«имел удовольствие удостоиться чести»
«процесс лежит на плечах городка»
«свёрел»
«изюменка»
-тся, -ться — тьфу.
Если бы это был единичный ляп — я бы написал в личку. Но, на мой взгляд, литературные и переводческие («rack» — набор?) достоинства статьи довольно низки. Автор явно поторопился выкладывать. Стоит познакомиться с девочкой-филологом и отдавать свои творения сначала на вычитку ей.
Он, кстати, единственный, кто внятно написал про организацию пула, в отличие о того же lair'а, у которого только невнятные пассы руками про «случаи бывают разные» и ничего конкретного.
всё равно правило «контейнер, который управляет процессами php» сохраняется
Если вы до сих пор не поняли, что меня задело, то вы не поняли вообще ни слова из всей ночной переписки.
мы с вами тут не методики защиты запросов обсуждали, а вашу дурацкую фразу.
а методика защиты одна — плейсхолдеры и белые списки. эскейпить параметры должен уже обработчик плейсхолдера, и то — только если нужно.
привет! :)