Комментарий о том, что делает код ИМХО излишен, так как это должно быть очевидно из самого кода и требует дополнительной работы при его модификации.
Другое дело — комментарий о цели кода. Очень помогает при чтении, а особенно при переделках, когда желательно быстро решить дилемму «прибить или оставить».
Я делал синтаксис with Using(MyObject, TMyObject.Create) do… а-ля C#. Причем можно и просто Using — кому как понятнее. Тем не менее для команды не покатило — плохо читалось другими разработчиками.
Нет — DFA-скорость при возможности достигается, но в общем случае не гарантируется. Главное преимущество чистого DFA для гугла (не надо думать об оптимизации самого регэкспа) в этом случае не реализуется.
Не поможет — для формирования строки запроса начинающие все равно будут использовать «удобное» встроенное форматирование и поствалидация не спасет.
Все нормальные библиотеки доступа к БД поддерживают параметры запросов сами и делают это максимально удобно для пользователя. В PHP же ввели простое форматирование строк на уровне языка (которое по определению пригодно только для вывода пользователю, и не подходит для обработки ввода и кодогенерации, о чем учебники деликатно умалчивают), но столь же простых средств формирования запросов (не только к БД) не сделали даже в штатных библиотеках. Результат — львиная доля кодя принципиально дырява как Тришкин кафтан.
Тогда нужны точные критерии, когда подрубается NFA (подозреваю, что при использовании сохраняющих скобок), иначе слова о линейном потреблении ресурсов останутся только словами.
Так запросы всегда можно сделать через одно место — воспретить это средствами языка не выйдет.
Проблема в том, что в PHP удобные базовые средства форматирования строк с низким порогом вхождения непригодны для продакшена как дырявые by design.
Т.е. язык не просто позволяет написать плохо, но внедряет антипаттерн с начала обучения.
Там не в работе СУБД дело, а в отвратительном механизме подстановки значений переменных в строку и не менее отвратительных заплатках на него вроде magic quote.
Еще неплохо дописать про настройку фильтрации информации с трекера — а то, например, приоритет для задачи в тасклист не попадает — неудобно. Для этого надо в настройке запроса задач добавить &q=${search}, и добавить параметр search, указав в нем поддерживаемый гуглокодом фильтр (например, priority:high)
ЕМНИП там DFA ищет образец целиком, а потом на него натравливается NFA. Т.е. с точки зрения расхода ресурсов это все-таки NFA, в котором DFA-дополнение используется в целях оптимизации
Весьма интересно. Но надо понимать, что линейное время поиска и расход памяти даются далеко не даром: принципиально не позволяют реализовать ряд фич вроде сверхжадных квантификаторов, опережающих и ретропроверок и тем более рекурсий и обратных вызовов. Плюс ряд возможностей вроде сохраняющих скобок и квантификаторов с указанным большим числом повторов весьма дороги в реализации.
Если уж давать ООП для тех, кто хоть один язык худо-бедно знает, то начинать надо со смолтолковской объектной модели, а потом уже показывать, почему в традиционных языках она превратилась в структуры+интерфейсы.
Паблик Морозов в дельфи и так делается одной строкой — достаточно объявить фиктивного наследника «кулака» — и вуаля! Не сработает только для секции strict protected. Используется для хаков архитектурных ошибок в сторонних библиотеках.
Это вы немножко не так поняли. Сейчас найти популярный однопротокольный клиент сложнее чем мультипротокольный — и первые пришедшие к нам на ум (мультипротокольники) тому примером.
Другое дело — комментарий о цели кода. Очень помогает при чтении, а особенно при переделках, когда желательно быстро решить дилемму «прибить или оставить».
Все нормальные библиотеки доступа к БД поддерживают параметры запросов сами и делают это максимально удобно для пользователя. В PHP же ввели простое форматирование строк на уровне языка (которое по определению пригодно только для вывода пользователю, и не подходит для обработки ввода и кодогенерации, о чем учебники деликатно умалчивают), но столь же простых средств формирования запросов (не только к БД) не сделали даже в штатных библиотеках. Результат — львиная доля кодя принципиально дырява как Тришкин кафтан.
Проблема в том, что в PHP удобные базовые средства форматирования строк с низким порогом вхождения непригодны для продакшена как дырявые by design.
Т.е. язык не просто позволяет написать плохо, но внедряет антипаттерн с начала обучения.