Это не цикл, а goto. С пониманием goto проблем обычно и нет. А сама инструкция «перейти наверх на пункт такой-то» — это и есть понятное обозначение конца блока, о чем я и говорил.
Цикл со счетчиком в виде списка на бумаге сделать не получится. Можно записать оператор словами, но если не знать как он работает, то будет непонятно.
Скрытый текст
Мне например сначала казалось, что словом for задается диапазон — «для» значений переменной i от A до B делать то-то (то есть как будто if (i >= A && i <= B)). При чтении обычного списка с листа оно примерно так и воспринимается, потому что это декларативное описание.
Работал с одним проектом на Yii2 + Postgres, там тоже логика была в базе. Модели можно было генерировать из типов (которые CREATE TYPE). Неудобно конечно, приходится вручную писать сохранение/загрузку, и модель становится больше похожа на репозиторий. Но думаю, если унифицировано именовать функции в БД, то можно сделать общую базовую AR-модель с findBySql() для чтения и полностью переопределенными методами для записи.
При обучении программированию учеников в школе вполне можно обойтись. На уроках программирования рассказывают, что происходит внутри на некотором уровне абстракции. Как и на уроках химии рассказывают о реакциях в терминах химии, а не квантовой физики.
А потом в середине листа встречается объявление функции и становится очень непонятно, почему ее операторы не исполняются, ведь мы уже привыкли, что программа это лист.
А почему у программы должна быть точка начала, почему начало в виде функции
Потому что у всего есть начало и конец, программа разделяется на функции, начало и конец программы это главная функция. Я о том, что если есть простая причина почему надо делать какие-то действия, то это более понятно, чем пример и без действий и без объяснений, который просто почему-то работает. Мне кажется, это не лишнее, это и есть та суть, которую нужно понять — как работает программа.
Впрочем, может я и не прав, никогда не обучал программированию новичков.
Выскажусь с позиции такого новичка. На первом курсе мы изучали одновременно C++ и Pascal, до этого я знал только Visual Basic на очень базовом уровне. Не было никаких проблем понять, что include нужен для подключения функции printf(), не только у меня, но и у многих других. Перевод строки в первых программах особо и не нужен, но после объяснения тоже все понятно — курсор в начало / курсор вниз. Писали void main(), главная функция — точка начала программы. У всего есть понятная причина, никаких магических конструкций, которые работают сами по себе.
Да и с Паскалем была прямая аналогия: include — uses, printf — write/writeln. begin/end — {} (только слова набирать дольше и опечатки в них иногда делаешь).
Ну прям секрет открыли. А еще unsigned int нельзя использовать для вычислений с результатом, который выходит за пределы 2^32.
Если посчитать первый множитель в обычном калькуляторе, то получается результат -7,9171109033773850490791882372801e+36, откуда видно, что для точных вычислений надо как минимум 37 разрядов.
Если бы мне в школе про списки начали говорить, я бы не понял еще больше.
— Отступы в списке можно сделать любого уровня, а не ровно 4 пробела, длина отступов на смысл не влияет.
— Отступы делаются для визуального разделения, а не для логического. Для логического как раз используются цифры и буквы.
— В списках нет циклов.
Я питон почти не знаю, мы в школе VB изучали, но когда начало и конец блока чем-то обозначены это более понятно.
Все так, мне просто подумалось, что какой-нибудь менеджер начитается таких советов и будет на основе них принимать решение, кого из новых разработчиков оставить после испытательного срока. Новые работники обычно не уточняют, что раньше не занимались проектом, это и так подразумевается.
Кто-то выполняет задачи быстро, а кому-то нужно время подумать.
«Я смотрю, ты уже давно не пишешь код»
Я бы добавил, что стоит оценивать не столько сам факт или время работы, сколько результат за некоторое достаточно большое время.
Потому что результат зависит не от одного действия, а от их совокупности. Работать 9 часов с перерывами обычно более продуктивно, чем без них.
Обращайте внимание не на скорость работы, а на способность «предсказывать», сколько времени потребуется на выполнение задачи. Главное – это то, насколько объективно коллега оценивает свои возможности.
Это не всегда работает, надо учитывать контекст. Если программисту дают задачу исправить ошибку в той части приложения, которой он до этого никогда не занимался, он вряд ли сможет дать правильную оценку, разве что наугад сказать.
Согласен. Пробовал читать «Гарри Поттера» на английском, так каждые 2 предложения в переводчик лазил. Хотя технические статьи понимаю нормально.
(не в качестве сравнения с Шекспиром, просто сюжет хорошо знаю)
Получаем модель
При инициализации модели.
Изменения строки
Транзакции
У вас в статье наверное штук 40 предложений, и четверть из них вот такие односложные заголовки. А также куча орфографических и пунктуационных ошибок. Это не статья, а огрызок. Вам сильно понравится, если кто-то предложит вам огрызок?
Вы бы хоть в Ворде орфографию проверили, раз сами не знаете.
всё это есть в документации
А зачем тогда нужна ваша статья? Про ORM тоже есть в документации. Кстати, вы бы хоть ссылку на нее оставили.
А где же join скажете вы? С join более сложнее
JOIN между таблицами — это связи между объектами, то есть буква R в ORM. Статья вроде как про ORM, а такой важной части нет.
«Я потом напишу, если попросите». Что за манера такая?
Я сейчас хочу создать простой в использовании интерфейс, использующий «перетаскивание», в котором любой может создать полнофункциональное комплексное приложение без какого-либо программирования.
В сложных программах количество блоков, переключателей и связей между ними будет настолько большим, что это будет аналог языка программирования. В этом основная проблема таких рассуждений.
Не все ассоциации к словам подходят по смыслу к другим словам в предложении. А еще бывает, что правильное ударение определяется из контекста, например в слове «замок». Неправильно определили исходное слово — получили неправильные ассоциации.
Это спор о терминологии, а не аргументы за или против.
— Новый оператор тоже будет конструкцией языка.
— Оператор <?= ?> это вывод, а оператор <?~ ?> это HTML-экранированный вывод.
— Вызов функции это тоже конструкция языка. Причем в прямом смысле слова: ZEND_AST_ECHO, ZEND_AST_CALL
Во фреймворках ENT_QUOTES | ENT_SUBSTITUTE. Отдельно ENT_QUOTES это менее строгий режим, и следовательно менее безопасный. Чарсет берется из настроек приложения. Задач, когда в документе одна кодировка, а в данных другая, и это действительно надо, очень мало. Как и не кодировать HTML-сущности в функции их кодирования. Я же говорю, это не повод из-за отдельных случаев не добавлять оператор, которым будут пользоваться многие. Некоторые фиче-реквесты еще в 2002 году созданы.
Она позиционируется как замена самому частому случаю. Я бы даже не стал называть это именно «замена». Сама функция никуда не денется.
Нестандартные — значит встречающиеся очень редко и специфичные для задачи. Думаю, стандартными в данном случае можно считать параметры, использующиеся по умолчанию в большинстве фреймворков.
Чарсет по умолчанию настраивается отдельно: string $encoding = ini_get("default_charset"), так что и данные в этой кодировке будут считаться валидными. Много ли таких проектов, у которых в базе одна кодировка, на странице другая, в приложении третья, и для всего этого еще и не сделана нормальная конвертация? Много ли таких «некоторых» от общего числа, кто использует четвертый параметр? Это наверное те, кто экранирует данные при сохранении в базу.
Как-то даже не очень хорошо получается. «Мы используем нестандартные параметры, поэтому из-за нас не должно быть оператора для стандартных параметров. И все обязаны делать так же, как мы, несмотря на то, что стандартных случаев гораздо больше».
вам уже в рамках этой статьи приводили минимум 2-3 отличающихся от вашего способа экранирования (различия в опциях)
В примерах указаны частные случаи соответствия стандартам. На правильность разметки и безопасность эти флаги не влияют. Все крупные фреймворки и шаблонизаторы используют другие сочетания флагов, причем похожие.
Я даже больше скажу. При любых флагах в htmlspecialchars кодируется только 5 основных сущностей (а, ну да, можно кавычки не кодировать, только смысл тогда экранировать данные). Сочетания флагов влияют только на способ кодирования апострофа, остальное различие сводится к разным способам обработки невалидных последовательностей. Много у вас в БД невалидных последовательностей?)
так напишите маленький препроцессор PHP-шаблонов, и там вводите свой новый синтаксис. Нечего подобным вещам делать на уровне языка
Вот если бы у меня такая необходимость встретилась в одном проекте, я бы так и сделал. Но она встречается во многих проектах. И результаты опросов показывают, что не у меня одного. Этот оператор не помешает никому, а поможет многим.
Цикл со счетчиком в виде списка на бумаге сделать не получится. Можно записать оператор словами, но если не знать как он работает, то будет непонятно.
if (i >= A && i <= B)). При чтении обычного списка с листа оно примерно так и воспринимается, потому что это декларативное описание.А потом в середине листа встречается объявление функции и становится очень непонятно, почему ее операторы не исполняются, ведь мы уже привыкли, что программа это лист.
Потому что у всего есть начало и конец, программа разделяется на функции, начало и конец программы это главная функция. Я о том, что если есть простая причина почему надо делать какие-то действия, то это более понятно, чем пример и без действий и без объяснений, который просто почему-то работает. Мне кажется, это не лишнее, это и есть та суть, которую нужно понять — как работает программа.
Впрочем, может я и не прав, никогда не обучал программированию новичков.
Да и с Паскалем была прямая аналогия: include — uses, printf — write/writeln. begin/end — {} (только слова набирать дольше и опечатки в них иногда делаешь).
Если посчитать первый множитель в обычном калькуляторе, то получается результат -7,9171109033773850490791882372801e+36, откуда видно, что для точных вычислений надо как минимум 37 разрядов.
— Отступы в списке можно сделать любого уровня, а не ровно 4 пробела, длина отступов на смысл не влияет.
— Отступы делаются для визуального разделения, а не для логического. Для логического как раз используются цифры и буквы.
— В списках нет циклов.
Я питон почти не знаю, мы в школе VB изучали, но когда начало и конец блока чем-то обозначены это более понятно.
Я бы добавил, что стоит оценивать не столько сам факт или время работы, сколько результат за некоторое достаточно большое время.
Потому что результат зависит не от одного действия, а от их совокупности. Работать 9 часов с перерывами обычно более продуктивно, чем без них.
Это не всегда работает, надо учитывать контекст. Если программисту дают задачу исправить ошибку в той части приложения, которой он до этого никогда не занимался, он вряд ли сможет дать правильную оценку, разве что наугад сказать.
(не в качестве сравнения с Шекспиром, просто сюжет хорошо знаю)
Ок, напишу.
У вас в статье наверное штук 40 предложений, и четверть из них вот такие односложные заголовки. А также куча орфографических и пунктуационных ошибок. Это не статья, а огрызок. Вам сильно понравится, если кто-то предложит вам огрызок?
Вы бы хоть в Ворде орфографию проверили, раз сами не знаете.
А зачем тогда нужна ваша статья? Про ORM тоже есть в документации. Кстати, вы бы хоть ссылку на нее оставили.
JOIN между таблицами — это связи между объектами, то есть буква R в ORM. Статья вроде как про ORM, а такой важной части нет.
«Я потом напишу, если попросите». Что за манера такая?
В сложных программах количество блоков, переключателей и связей между ними будет настолько большим, что это будет аналог языка программирования. В этом основная проблема таких рассуждений.
Напомнило: http://bash.im/quote/397276 :)
— Новый оператор тоже будет конструкцией языка.
— Оператор <?= ?> это вывод, а оператор <?~ ?> это HTML-экранированный вывод.
— Вызов функции это тоже конструкция языка. Причем в прямом смысле слова: ZEND_AST_ECHO, ZEND_AST_CALL
Нестандартные — значит встречающиеся очень редко и специфичные для задачи. Думаю, стандартными в данном случае можно считать параметры, использующиеся по умолчанию в большинстве фреймворков.
string $encoding = ini_get("default_charset"), так что и данные в этой кодировке будут считаться валидными. Много ли таких проектов, у которых в базе одна кодировка, на странице другая, в приложении третья, и для всего этого еще и не сделана нормальная конвертация? Много ли таких «некоторых» от общего числа, кто использует четвертый параметр? Это наверное те, кто экранирует данные при сохранении в базу.Как-то даже не очень хорошо получается. «Мы используем нестандартные параметры, поэтому из-за нас не должно быть оператора для стандартных параметров. И все обязаны делать так же, как мы, несмотря на то, что стандартных случаев гораздо больше».
В примерах указаны частные случаи соответствия стандартам. На правильность разметки и безопасность эти флаги не влияют. Все крупные фреймворки и шаблонизаторы используют другие сочетания флагов, причем похожие.
Symfony — ENT_QUOTES | ENT_SUBSTITUTE
Yii — ENT_QUOTES | ENT_SUBSTITUTE
Zend — ENT_QUOTES | ENT_SUBSTITUTE
Twig — ENT_QUOTES | ENT_SUBSTITUTE
Smarty — ENT_QUOTES
Blade — ENT_QUOTES
Facebook XHP — [по умолчанию]
Я даже больше скажу. При любых флагах в htmlspecialchars кодируется только 5 основных сущностей (а, ну да, можно кавычки не кодировать, только смысл тогда экранировать данные). Сочетания флагов влияют только на способ кодирования апострофа, остальное различие сводится к разным способам обработки невалидных последовательностей. Много у вас в БД невалидных последовательностей?)
htmlspecialchars()
php_escape_html_entities_ex()
determine_entity_table()
таблицы
Вот если бы у меня такая необходимость встретилась в одном проекте, я бы так и сделал. Но она встречается во многих проектах. И результаты опросов показывают, что не у меня одного. Этот оператор не помешает никому, а поможет многим.