Я к этому, в общем-то, и не стремился :) Проблема в том, что когда вы используете возможности из разряда нестандартизированных и экспериментальных, а кодовая база проекта велика, при внесенении в стандарт существенных изменений, вы гарантировано получите геморрой. Babel будет изменен так, чтобы соответствовать новым изменениям. А вам придется поменять код, который от них зависит.
Проблема в том, что декораторы не являются утвержденным стандартном… Это ведь ES7, если не ошибаюсь. Хотя внедрение поддержки уже начато многими библиотеками. Babel поддерживает, например. Но в экспериментальном порядке:
These proposals are subject to change so use with extreme caution. Babel may update without warning in order to track spec changes.
Спасибо за статью. Подскажите, как вы решили вопрос с отсутствием возможности использовать миксины в определении классов React компонентов? Или просто отказались от миксинов?
Разве C# и Java не похожи? :) Конечно, можно долго спорить и том, что именно можно называть «похожестью», но так уж сложилось, что многие конструкции почти во всех ООП языках выглядят «похожим» образом.
Насколько я помню, это объяснялось тем, что в PHP6 предполагали вводить совсем другие изменения (в частности, родные Unicode-строки). И, как водится, появилось огромное количество книг и статей с названиями типа «Программируем на PHP6», несмотря на то, что изменения даже утверждены еще не были.
Поскольку roadmap сильно изменился, чтобы не вводить в заблуждение пользователей, решили перепрыгнуть через цифру.
Раньше простую гостевую делали по учебниками и статьям и было приятно, было в кайф, все было просто и понятно.
И каждый раз каждый из нас писал гостевую с нуля. Потом прикручивал к ней статические страницы, потом динамические, потом новости, потом блоги, потом галереи картинок, форумы и… ВУАЛЯ! Так рождались самописные лапшеобразные фреймворки-велосипеды :)
Я только что попробовал сделать SET AUTOCOMMIT = OFF на своем Postgres. Ошибку процитировал.
В документации, ссылку на которую вы привели, говорится об использовании autocommit в ecpg окружении. autocommit выключить нельзя начиная еще с версии 7.4
Раньше мыскль рос до постгреса, а в последнее время наоборот, постгрес берет лучшее из мыскля.
Можете пару примеров лучшего привести, что еще взято из MySQL в Postgres?
Мне кажется, что сама идея UPSERT для MySQL не инновационна. Он ведь был и в других базах данных. Скажем, в SQLite есть «ON CONFLICT». Просто MySQL самая популярная СУБД, в которой он есть.
Доктрину пытаются использовать как любую другую ORM
Я думаю, это проблема не языка («it’s not suited for PHP»), а непонимание идеологии библиотеки. Скажем, я могу пытаться использовать Hibernate в ActiveRecord стиле. И получится примерно та же самая ситуация.
Своих проблем добавляет и сама доктрина, вводя такие понятия как сущность, репозиторий
Я думаю, это не доктрина добавляет проблем. Понятия «сущность» и «репозитарий» — базовые понятия в разработке. Эти понятия в той или иной форме используются в любой DataMapper ORM библиотеке. Да и в ActiveRecord ORM эти понятия тоже встречаются. И их непонимание — это не проблема библиотеки, а проблема квалификации разработчика.
слой инфраструктуры сильно смешивается со слоем предметной области
Опять же, это проблема не Doctrine, а квалификации разработчика, не так ли? Разве ActiveRecord ORM сложно использовать так, чтобы «все смешалось»?
Мне тоже статья показалась несколько надуманной. Надо только отметить, что все претензии относятся к оригинальной статье, а не к автору перевода.
Меня поразили еще самые первые строки: «I’m not saying Doctrine <...> shouldn’t be used. I’m just saying it’s not suited for PHP And this can lead to critical problems if misused».
Фича действительно получается недоделанной. Во-первых, все проверки все равно проходят в рантайме и пока функцию никто не вызвал, невозможно узнать, что она написана или используется неправильно.
Это верно. Возможно, это должно нас всех стимулировать к написанию юнит-тестов по поводу и без :)
Мы ведь вообще не об этом сейчас говорим. Мы говорим о том, что какова бы ни была сложность кода, если он предназначен для демонстрации изменений, которые были произведены в языке, она не имеет значения. Потому что читать и поддерживать этот код никто не будет. Он — просто иллюстрация.
Совершенно неважно что это за код и откуда, если он просто иллюстрирует возможности языка
Конечно, но только в том случае, когда фича является экспериментальной.
Поскольку roadmap сильно изменился, чтобы не вводить в заблуждение пользователей, решили перепрыгнуть через цифру.
И каждый раз каждый из нас писал гостевую с нуля. Потом прикручивал к ней статические страницы, потом динамические, потом новости, потом блоги, потом галереи картинок, форумы и… ВУАЛЯ! Так рождались самописные лапшеобразные фреймворки-велосипеды :)
В документации, ссылку на которую вы привели, говорится об использовании autocommit в ecpg окружении. autocommit выключить нельзя начиная еще с версии 7.4
www.postgresql.org/message-id/20050703233108.GA40409@winnie.fuhr.org
Можете пару примеров лучшего привести, что еще взято из MySQL в Postgres?
Мне кажется, что сама идея UPSERT для MySQL не инновационна. Он ведь был и в других базах данных. Скажем, в SQLite есть «ON CONFLICT». Просто MySQL самая популярная СУБД, в которой он есть.
Autocommit для пользовательских SQL запросов в PostgreSQL по умолчанию включен.
«embedded SQL programs», о которых говорится в мануале, — это С программы, ипользующие ecpg. В Postgres 9.4 выключить autocommit невозможно:
Я думаю, это проблема не языка («it’s not suited for PHP»), а непонимание идеологии библиотеки. Скажем, я могу пытаться использовать Hibernate в ActiveRecord стиле. И получится примерно та же самая ситуация.
Я думаю, это не доктрина добавляет проблем. Понятия «сущность» и «репозитарий» — базовые понятия в разработке. Эти понятия в той или иной форме используются в любой DataMapper ORM библиотеке. Да и в ActiveRecord ORM эти понятия тоже встречаются. И их непонимание — это не проблема библиотеки, а проблема квалификации разработчика.
Опять же, это проблема не Doctrine, а квалификации разработчика, не так ли? Разве ActiveRecord ORM сложно использовать так, чтобы «все смешалось»?
Полностью согласен.
Меня поразили еще самые первые строки: «I’m not saying Doctrine <...> shouldn’t be used. I’m just saying it’s not suited for PHP And this can lead to critical problems if misused».
Это верно. Возможно, это должно нас всех стимулировать к написанию юнит-тестов по поводу и без :)
Совершенно неважно что это за код и откуда, если он просто иллюстрирует возможности языка