Тоже пользуюсь тортиллой. В консоли удобно делать повторяющиеся действия из нескольких команд, типа checkout/pull/checkout/rebase, можно названия веток вынести в переменные, и копи-пастить весь набор команд в консоль. Или разные хитрые вещи для управления репозиторием, которых нет в GUI.
А вещи, которые требуют внимания, выбора, и работы с текстом, удобнее делать в GUI — diff файлов перед коммитом, разбиение/слияние коммитов, интерактивный rebase, разрешение конфликтов. Дело личных предпочтений, конечно, но при правильном применении GUI помогает сэкономить время.
Ради прикола можно назвать это «КЛАССное программирование» от слова «класс» по аналогии с функциональным программированием.
Почему вы в таком случае называете обмен сообщениями объектно-ориентированным программированием? Это можно назвать «сообщение-ориентированное программирование» или «коммуникативное программирование». Потому что там сообщениями обмениваются объекты? Ну так методы друг друга вызывают тоже объекты, а не классы.
Все программисты думают что C++ поддерживает ООП
Самое смешное в этих статьях то, что многие под ООП понимают некий принцип когда-то заложенный в C++. И редко кто реально понимает что такое ООП. Вдруг мне показалось что 99% программистов вообще плохо понимают что такое ООП.
Вам говорят, что ООП это многозначное понятие. Вы же говорите, что никто не понимает, что такое ООП, что есть только одно значение, которое было изначально. Оба смысла этого термина произошли от слова «объект», но используются в немного разных контекстах. Не надо подменять одно другим, или говорить, что все, кто использует другое значение, дураки, которые ничего не понимают.
Подскажите, а зачем нужна такая сложная связка Excel/Access/VBA/MSSQL/PHP/расширение для Chrome/DLL на C++, к тому же с лицензиями? Как я понял, у вас все равно есть веб-часть, можно ведь было просто сделать все на PHP+MySQL или PHP+MSSQL, и получить любые формы, отчеты и чарты, используя возможности HTML.
Эм. То есть вы предлагаете, чтобы всякие индексы БД, алгоритмы кэширования, очереди и грин-треды изучали UX-дизайнеры и директора, а потом выдавали вам на блюдечке готовую инструкцию с описанием архитектуры программы и ссылками на описание конкретного алгоритма?
Ни разу на собеседовании вообще меня не спросили, что такое ООП, если дело доходило до него, но спросили про инкапсуляцию, наследование и полиморфизм, атрибуты доступа, как это работает с наследованием и прочие технические детали целевой технологии
Потому что это надо знать, чтобы пользоваться языком программирования для решения задач. От того, что кто-то выучил фразу «ООП — это представление объектов окружающего мира», знание и умение программирования у него не появится.
Я сам проводил собеседования и спрашивал у людей то, как они понимают ООП. Мне рассказывали про классы, объекты, интерфейсы, атрибуты доступа, инкапсуляцию, наследование, полиморфизм и т.д. При этом не часто кто-то мог чётко ответить на то, в чём главная идея и профит от ООП.
То есть вы загадали какой-то ответ, который считаете единственно правильным, и ждете, что разработчики его угадают? Телепатию еще не изобрели. Про ООП написано множество статей на разные темы с разных точек зрения, про это можно расуждать дольше, чем длится собеседование, а вы хотите, чтобы люди вам сказали какие-то определенные несколько слов, которые вы считаете ответом на свой вопрос. При этом, тех, кто не угадал, вы почему-то называете кучей дурачков.
В своем базисе у чашек, кружек и бокалов лежит идея какого-то абстрактного сосуда, метод использования которого — из него пьют, а свойства которого — он может содержать внутри жидкость и сделан из какого-то материала.
Туда можно сахар насыпать, к примеру. Ваша чашка в коде не реализует поведение реальной чашки из бизнес-требований (или из окружающего мира).
class Cup extends Vessel implements Knob
{
public function take(Holder $with)
}
Этот пример не очень аккуратный и продуманный, зато полностью передает то, как из концепции ООП вытекает всё то, что так требуют на собеседованиях.
Мне вот из этого кода кажется, что чашка берет держатель. Как-то не очень это передает концепцию ООП.
Предлагаемая реализация немного изменилась. Больше нет никаких трюков с пространствами имен или магических констант. Причиной для задания PHPEscaper как ZEND_NAME_NOT_FQ была возможность использования в сторонних модулях своего обработчика вне зависимости от обработчика приложения. Но, возможно, это добавит больше проблем, чем решит.
Они работают аналогично set_error_handler() / restore_error_handler(). Пользовательский обработчик назначается не на конкретный контекст, а на вызов оператора в целом.
Оператор (или тег) <?* $str, $context ?> компилируется в следующее AST:
echo escape_handler_call($str, $context);
Второй аргумент также необязательный. Функция escape_handler_call() просто передает в текущий обработчик оба аргумента как есть. Контекст по умолчанию задается в пользовательском обработчике.
Наличие обработчика по умолчанию пока под вопросом, так как есть возможность 'встроенной' неправильной работы оператора с одним аргументом в не-HTML шаблонах — CSV, plain text. Возможно, стоит просто добавить возможность его разрегистрировать.
Также есть небольшой вопрос, добавлять ли эти функции в глобальное пространство имен, или лучше обернуть в статический класс.
Нашел хорошую аналогию. Вызывать экранирующую функцию вручную в каждом месте вывода значения — это то же самое, как вызывать конструктор вручную после каждого оператора 'new':
(new User)->__construct(...);
(new Profile)->__construct(...);
PHP (рекурсивный акроним словосочетания PHP: Hypertext Preprocessor) — это распространенный язык программирования общего назначения с открытым исходным кодом. PHP сконструирован специально для ведения Web-разработок и его код может внедряться непосредственно в HTML.
Прочитайте пожалуйста коммент выше с описанием реализации. Там есть примеры, как использовать этот оператор для любых других контекстов, не только HTML.
Про причины создания отдельного оператора для HTML, другие подобные функции, RFC для них, и сравнение их с HTML применительно к веб-разработке, написано в более ранних комментариях и в самой статье.
Еще подумал, что такой оператор можно использовать не только для экранирования, а для любых контекстно-зависимых трансформаций текста — переводы, форматирование чисел и дат, и т.д. Особенно если сделать возможность передавать второй аргумент массивом.
А если им выводились данные с HTML? <?= $form->field(...) ?>
Замена сильно сломает обратную совместимость, надо будет много кода переписать. По одной из ссылок на предыдущие обсуждения есть похожее предложение, там человек заменил обработку байт-кода для echo в виртуальной машине. Как я понял, обратная совместимость это одна из причин, почему его не приняли.
Вообще да, было бы лучше. если бы изначально короткий оператор вывода был с HTML экранированием, а все остальное выводилось через <?php echo ?>. Но имеем то, что имеем.
1. Я думал о случае наподобие $this->escape($str, 'html'), но не придумал, как нормально добавить переменную с объектом.
Переменная же может иметь любое имя. Третьим параметром получается слишком сложно и многословно.
Но можно сделать так:
<?php
...
// в приложении, при создании объекта View
PHPEscaper::registerHandler([$this, 'escapeHtml'], 'html');
...
// после завершения рендернга
PHPEscaper::unregisterHandler('html');
?>
<?php
// в представлении (будет вызван PHPEscaper::escape, который вызовет callable объект [$this, 'escapeHtml'])
?>
<?* $str, 'html' ?>
2. Ну не сильно тяжелее, чем любое умножение или та же тильда)
Одиночная кавычка может сломать разные парсеры, что в общем-то и заметно.
Как вариант можно двоеточие:
<?: $str ?>
(хм, пожалуй, его удобнее набирать, чем *, надо подумать над этим)
При замене на = ошибки не будет, это валидная конструкция, стандартный оператор же никуда не девается. Да в общем-то ошибка и необязательна, варианты оператора распознаются только если включены короткие теги, и ничего опасного при этом не происходит, просто это более строгое поведение, если новый оператор не будет вообще распознаваться в предыдущих версиях.
Какие мысли у вас возникают при вопросе «Это вы зашли в банк вчера вечером после его закрытия? А как можете доказать?»? Мысли это ассоциации, то есть реакция нейронов. Читаем все реакции — получаем всю информацию. Примерно то же самое, как незашифрованный сетевой траффик посмотреть.
Считывать реакции нервных клеток и сейчас могут. Просто не в таком масштабе.
И возможность записи никак не меняет того, что можно определить соответствие мыслей человека и его слов. Про измененные воспоминания тоже можно наврать.
Полное чтение мыслей покажет и то, что человек делал вчера вечером, о чем он помнит. Неважно, как он к этому относится, воспоминания о действиях все равно будут.
http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/language_plural_rules.html
А вещи, которые требуют внимания, выбора, и работы с текстом, удобнее делать в GUI — diff файлов перед коммитом, разбиение/слияние коммитов, интерактивный rebase, разрешение конфликтов. Дело личных предпочтений, конечно, но при правильном применении GUI помогает сэкономить время.
Почему вы в таком случае называете обмен сообщениями объектно-ориентированным программированием? Это можно назвать «сообщение-ориентированное программирование» или «коммуникативное программирование». Потому что там сообщениями обмениваются объекты? Ну так методы друг друга вызывают тоже объекты, а не классы.
Вам говорят, что ООП это многозначное понятие. Вы же говорите, что никто не понимает, что такое ООП, что есть только одно значение, которое было изначально. Оба смысла этого термина произошли от слова «объект», но используются в немного разных контекстах. Не надо подменять одно другим, или говорить, что все, кто использует другое значение, дураки, которые ничего не понимают.
Потому что это надо знать, чтобы пользоваться языком программирования для решения задач. От того, что кто-то выучил фразу «ООП — это представление объектов окружающего мира», знание и умение программирования у него не появится.
То есть вы загадали какой-то ответ, который считаете единственно правильным, и ждете, что разработчики его угадают? Телепатию еще не изобрели. Про ООП написано множество статей на разные темы с разных точек зрения, про это можно расуждать дольше, чем длится собеседование, а вы хотите, чтобы люди вам сказали какие-то определенные несколько слов, которые вы считаете ответом на свой вопрос. При этом, тех, кто не угадал, вы почему-то называете кучей дурачков.
Туда можно сахар насыпать, к примеру. Ваша чашка в коде не реализует поведение реальной чашки из бизнес-требований (или из окружающего мира).
Мне вот из этого кода кажется, что чашка берет держатель. Как-то не очень это передает концепцию ООП.
Есть 3 функции.
Они работают аналогично
set_error_handler() / restore_error_handler(). Пользовательский обработчик назначается не на конкретный контекст, а на вызов оператора в целом.Оператор (или тег)
<?* $str, $context ?>компилируется в следующее AST:Второй аргумент также необязательный. Функция
escape_handler_call()просто передает в текущий обработчик оба аргумента как есть. Контекст по умолчанию задается в пользовательском обработчике.Наличие обработчика по умолчанию пока под вопросом, так как есть возможность 'встроенной' неправильной работы оператора с одним аргументом в не-HTML шаблонах — CSV, plain text. Возможно, стоит просто добавить возможность его разрегистрировать.
Также есть небольшой вопрос, добавлять ли эти функции в глобальное пространство имен, или лучше обернуть в статический класс.
Прочитайте пожалуйста коммент выше с описанием реализации. Там есть примеры, как использовать этот оператор для любых других контекстов, не только HTML.
Про причины создания отдельного оператора для HTML, другие подобные функции, RFC для них, и сравнение их с HTML применительно к веб-разработке, написано в более ранних комментариях и в самой статье.
<?= $form->field(...) ?>Замена сильно сломает обратную совместимость, надо будет много кода переписать. По одной из ссылок на предыдущие обсуждения есть похожее предложение, там человек заменил обработку байт-кода для echo в виртуальной машине. Как я понял, обратная совместимость это одна из причин, почему его не приняли.
Вообще да, было бы лучше. если бы изначально короткий оператор вывода был с HTML экранированием, а все остальное выводилось через
<?php echo ?>. Но имеем то, что имеем.Переменная же может иметь любое имя. Третьим параметром получается слишком сложно и многословно.
Но можно сделать так:
2. Ну не сильно тяжелее, чем любое умножение или та же тильда)
Одиночная кавычка может сломать разные парсеры, что в общем-то и заметно.
Как вариант можно двоеточие:
(хм, пожалуй, его удобнее набирать, чем
*, надо подумать над этим)При замене на = ошибки не будет, это валидная конструкция, стандартный оператор же никуда не девается. Да в общем-то ошибка и необязательна, варианты оператора распознаются только если включены короткие теги, и ничего опасного при этом не происходит, просто это более строгое поведение, если новый оператор не будет вообще распознаваться в предыдущих версиях.
И возможность записи никак не меняет того, что можно определить соответствие мыслей человека и его слов. Про измененные воспоминания тоже можно наврать.