Оба варианта слишком ломают обратную совместимость. С тем, что будут забывать использовать, никакой проблемы нет, потому что нет никакого отличия от текущей ситуации. К тому же, забывать можно, если используется редко, а экранированный вывод используется часто.
<?= e($anyString) ?>
Отличий от предложенного варианта нет, но сущности не плодятся.
Плодится копи-паста. И если случайно убрать символ «e», то выведутся небезопасные данные. А если убрать специальный оператор, то не выведется ничего.
Пример ошибки с XSS?
<?= $anyString ?>
Тут вместо <?~ ?> использовали <?= ?> из-за невнимательности, вызванной привычным использованием <?= ?>
Ну так сейчас только так и выводится. Небезопасный вывод не должен быть привычным использованием. В 90% случаев данные нужно экранировать для HTML, поэтому с новым оператором привычным будет его использование.
Шаблонизаторы же такой проблемы лишены, и в них нужно задумываться не для экранирования, а для отмены экранирования. Хочу заметить, что с шаблонами работают фронтендеры, и их навыки в PHP минимальны.
То есть надо каждому новому фронтендеру объяснять, что у нас есть специальная функция e(), которую надо вызывать всегда и везде, и что им надо забыть про функциию h(), которая была у них на предыдущем проекте? Кроме того, я имею в виду в первую очередь уже существующие проекты, в которых уже не используются шаблонизаторы. С тем, что шаблонизаторы это хорошо, никто и не спорит.
Или мы заведём <?~ ?> для HTML вне тегов, <?# ?> для строк в json, <?@#$*&^% ?> для LIKE выражений в SQL и т.д.
Нет. Это оператор специально для HTML-контекста. Потому что это самая частая операция, и она применяется совместно с другими контекстами. И вывод данных из PHP напрямую в JS это не настолько частая операция, как вывод данных в HTML-контекст. С LIKE-выражениями вполне справляются движки для работы с БД, они используются везде, в отличие от шаблонизаторов.
Это не какая-то моя локальная проблема, это операция, которая часто встречается во многих проектах. И чтобы каждый не решал таким способом свои проблемы, существует процесс RFC. Данная статья нужна для того, чтобы решить, стоит ли его начинать, узнать мнение сообщества, аргументы за и против. Потому что могут быть причины, с которыми я не сталкивался и о которых не подумал. Пока что все аргументы против сводятся к вариантам «мне не нравится странный синтаксис» и «используйте шаблонизаторы, PHP уже не шаблонизатор», либо к контекстам экранирования. По поводу шаблонизаторов и контекста я и написал в статье, и пока что нет аргументов в пользу того, что я не прав.
Проблема не в длине названия функции, а в том, что есть возможность написать без нее, специально или по невнимательности, что бывает довольно часто. И приходится постоянно держать в голове, что я не могу просто воспользоваться оператором <?= ?>, а надо туда еще что-то дописывать, причем дописывать всегда одно и то же.
Аргументируйте пожалуйста. Я считаю, что это не бесполезный хлам, это нужная и часто используемая операция. Один оператор не превратит PHP в хороший шаблонизатор и не заставит исчезнуть другие шаблонизаторы, зато поможет в разработке тех проектов, где шаблонизатора нет. Кроме того, такой аргумент можно было бы рассмотреть, если бы в PHP не добавлялись новые операторы для уже существующих действий — ?? или <=>. Много ли людей пишут свою сортировку на PHP? А данные из БД выводят практически все.
Оператор без тильды сейчас не используется. Написать случайно <?= ?> сложнее, потому что надо символы по-другому набирать. Скопировать <?= ?> из другого места можно, но если этот оператор будет применяться всегда при выводе в HTML, то и эта проблема решится. Проблема с функцией в том, что можно вывести без функции, а без оператора вывести ничего не получится.
Написание функции с коротким именем не решает проблему копи-пасты или невнимательности. Кроме того, дело не в копи-пасте как таковой, а в том, что это очень частая операция. 90% выводимых данных — это данные из БД, и только иногда нам надо вывести готовый HTML-контент. Ну и просто это логично, что в языке для веб-программирования должен быть оператор безопасного вывода данных в HTML-окружение.
Видимо, вам очень нравится теоретизировать. Мне теперь тоже начинает казаться, что вы живете в стране розовых пони. Потому что EAV, и основных таблиц у вас всего 2 — iblock_element и iblock_element_property. В них, кроме товаров, могут храниться еще и новости, например. К ним сбоку приделывается catalog_price, и поверх всего этого навешивается система скидок. Чтобы понять, в каком порядке и по какому условию надо джойнить iblock_element_property с iblock_element_property, надо залезть в код.
Очевидно, того, о чем он говорит, и по поводу чего вы ему возражаете. Конкретно — что бывают ситуации, когда нет возможности отказаться от работы с неприятным кодом. Именно для того, чтобы были средства, чтобы «продолжать мониторить крупные компании».
И что? 2 недели не поиск?
Вы сказали, что все зависит только от человека. В отношении поиска работы это не так, и человека могут не брать только потому, что он нигде раньше не работал, и у него нет практического опыта. У вас не было достаточно времени, чтобы с этим познакомиться на собственном опыте, потому что 2 недели поиска новой работы это вполне нормально даже для опытного специалиста.
Я привел пример как можно переехать в другой город работая на фрилансе.
Я вам тоже приведу пример. У меня только через 2 недели появилось первое согласие на отклик. И за следующие 2 недели тоже всего 2 штуки. Потому что я джуниор, у меня нет портфолио и положительных откликов. Я заработал 30 баксов, а прошел месяц, и за квартиру надо платить. А так да, теоретически переехать можно, потом когда-нибудь.
А сколько по вашему?
Нисколько, речь не об этом. Вы сказали «не думаю что сильно много». Я предложил вам не гадать, а попробовать. Также вы сказали, что «Перенести данные» и «Разрабатывать на битриксе» немного разные понятия. Это не так, и чтобы разобраться, как правильно перенести данные, вам надо разобраться в логике работы битрикса, то есть какое-то время с ним поработать. Это не означает, что надо обязательно писать новый код, но надо разобраться в старом. В общем-то, это справедливо для любой сложной системы, но весь вопрос в коэффициентах.
Человек правильно вам говорит. Если вы с этим не сталкивались, это не значит, что этого нет.
Т.е. есть часть которая готова собеседовать удаленно и в случае успеха приглашать на работу.
Ок, часть джуниоров попала к этой части работодателей. Что делать остальным? А еще, представьте себе, бывает так, что нет денег на переезд в другой город. Как их заработать? Правильно, выполняя такую работу, которую готовы доверить джуниору без опыта.
Нашел работу на второй неделе поисков, взяли в небольшую компанию которая работала с европой. Проработал там 1,5 года
Вот вы и признались, что у вас нет опыта в поиске работы. Вы искали работу всего 2 недели, а в следующий раз вы были уже не джуниор.
Для чего? Для переноса данных имея на руках базу? Не думаю что сильно много.
Поставьте себе демо-версию битрикса и попробуйте вынести все сущности, связанные с товарами, в отдельные таблицы. С сохранением ценообразования и прочими необходимыми финтифлюшками. Посмотрите, сколько у вас уйдет времени и других ресурсов.
Да, не подумал. Раз уж тут коллекция вариантов, то вот исправленный и более короткий (для MySQL):
SELECT CONCAT_WS(',',
GROUP_CONCAT( IF(f = t, f, CONCAT(f, '-', t)) ),
CONCAT((@n + 1), '...')
) AS result
FROM (
SELECT (@n + 1) AS f, (id - 1) AS t, @n := id AS c
FROM (SELECT @n := 0) t, test
ORDER BY id
) t2
WHERE t >= f
Согласен, мне тоже это не очень нравится. Но зачем использовать именно лямбды, если можно просто написать линейный код, и дать понятное название переменной с результатом вычисления?
… давайте приведу несколько синтетический пример
… Давайте проведем отдаленный от реальности эксперимент
А какой смысл в таких примерах, неужели у вас нет нормального рабочего примера, не оторванного от реальности? Может, если примера нет, то и проблемы нет?)
По-моему, тут есть неправильное разбиение на функции. В rubles_per_unit() надо передавать готовые значения. Тогда это будет не вспомогательная функция, а вполне рабочая, которую можно вызывать из других мест. А для map вполне естественно указывать лямбды, потому что без map это будет просто тело цикла.
Пример (Ruby не знаю, поэтому на PHP, уж извините):
class CentralBankExchangeRate
{
public function function rate_hash()
{
$uri = URI::parse('http://www.cbr.ru/scripts/XML_daily.asp');
$xml_with_currencies = $uri->read();
$rates = Hash::from_xml($xml_with_currencies)['ValCurs']['Valute'];
$rate_hash = [];
foreach ($rates as $rate) {
$rate_hash[$rate['CharCode']] = $this->rubles_per_unit($rate['Value'], $rate['Nominal']);
}
}
public function rubles_per_unit($value, $nominal)
{
return ($value / $nominal);
}
}
<? ?>надо включать.Плодится копи-паста. И если случайно убрать символ «e», то выведутся небезопасные данные. А если убрать специальный оператор, то не выведется ничего.
Ну так сейчас только так и выводится. Небезопасный вывод не должен быть привычным использованием. В 90% случаев данные нужно экранировать для HTML, поэтому с новым оператором привычным будет его использование.
То есть надо каждому новому фронтендеру объяснять, что у нас есть специальная функция e(), которую надо вызывать всегда и везде, и что им надо забыть про функциию h(), которая была у них на предыдущем проекте? Кроме того, я имею в виду в первую очередь уже существующие проекты, в которых уже не используются шаблонизаторы. С тем, что шаблонизаторы это хорошо, никто и не спорит.
Нет. Это оператор специально для HTML-контекста. Потому что это самая частая операция, и она применяется совместно с другими контекстами. И вывод данных из PHP напрямую в JS это не настолько частая операция, как вывод данных в HTML-контекст. С LIKE-выражениями вполне справляются движки для работы с БД, они используются везде, в отличие от шаблонизаторов.
Это не какая-то моя локальная проблема, это операция, которая часто встречается во многих проектах. И чтобы каждый не решал таким способом свои проблемы, существует процесс RFC. Данная статья нужна для того, чтобы решить, стоит ли его начинать, узнать мнение сообщества, аргументы за и против. Потому что могут быть причины, с которыми я не сталкивался и о которых не подумал. Пока что все аргументы против сводятся к вариантам «мне не нравится странный синтаксис» и «используйте шаблонизаторы, PHP уже не шаблонизатор», либо к контекстам экранирования. По поводу шаблонизаторов и контекста я и написал в статье, и пока что нет аргументов в пользу того, что я не прав.
??или<=>. Много ли людей пишут свою сортировку на PHP? А данные из БД выводят практически все.Ну и набирать удобнее, и перепутать сложнее.
Нет там связей, ни одного foreign key во всем дампе. Со связями конечно все проще, никто и не спорит.
Речь шла об одном конкретном продукте.
Нет желания играть в телепатию, извините.
Мир шире, чем вам кажется.
Очевидно, того, о чем он говорит, и по поводу чего вы ему возражаете. Конкретно — что бывают ситуации, когда нет возможности отказаться от работы с неприятным кодом. Именно для того, чтобы были средства, чтобы «продолжать мониторить крупные компании».
Вы сказали, что все зависит только от человека. В отношении поиска работы это не так, и человека могут не брать только потому, что он нигде раньше не работал, и у него нет практического опыта. У вас не было достаточно времени, чтобы с этим познакомиться на собственном опыте, потому что 2 недели поиска новой работы это вполне нормально даже для опытного специалиста.
Я вам тоже приведу пример. У меня только через 2 недели появилось первое согласие на отклик. И за следующие 2 недели тоже всего 2 штуки. Потому что я джуниор, у меня нет портфолио и положительных откликов. Я заработал 30 баксов, а прошел месяц, и за квартиру надо платить. А так да, теоретически переехать можно, потом когда-нибудь.
Нисколько, речь не об этом. Вы сказали «не думаю что сильно много». Я предложил вам не гадать, а попробовать. Также вы сказали, что «Перенести данные» и «Разрабатывать на битриксе» немного разные понятия. Это не так, и чтобы разобраться, как правильно перенести данные, вам надо разобраться в логике работы битрикса, то есть какое-то время с ним поработать. Это не означает, что надо обязательно писать новый код, но надо разобраться в старом. В общем-то, это справедливо для любой сложной системы, но весь вопрос в коэффициентах.
Ок, часть джуниоров попала к этой части работодателей. Что делать остальным? А еще, представьте себе, бывает так, что нет денег на переезд в другой город. Как их заработать? Правильно, выполняя такую работу, которую готовы доверить джуниору без опыта.
Вот вы и признались, что у вас нет опыта в поиске работы. Вы искали работу всего 2 недели, а в следующий раз вы были уже не джуниор.
Поставьте себе демо-версию битрикса и попробуйте вынести все сущности, связанные с товарами, в отдельные таблицы. С сохранением ценообразования и прочими необходимыми финтифлюшками. Посмотрите, сколько у вас уйдет времени и других ресурсов.
А какой смысл в таких примерах, неужели у вас нет нормального рабочего примера, не оторванного от реальности? Может, если примера нет, то и проблемы нет?)
По-моему, тут есть неправильное разбиение на функции. В rubles_per_unit() надо передавать готовые значения. Тогда это будет не вспомогательная функция, а вполне рабочая, которую можно вызывать из других мест. А для map вполне естественно указывать лямбды, потому что без map это будет просто тело цикла.
Пример (Ruby не знаю, поэтому на PHP, уж извините):