Ну, костыль не костыль, но Вы уверены, что Вам всегда нужно таскать в замыкание весь контекст? А если нужно, то возможно Вы что-то делаете не так?
Ну, и к тому же, один из пунктов философии Python, если мне не изменяет память — «Явное лучше, чем неявное» ;)
>>принципу Утиной Типизации
Самое ужасное, как мне кажется, что может быть, это когда два объекта одного класса имеют разный набор методов и пр. Удобно? Вполне возможно. Поддерживаемо через 6-12 месяцев? Сомневаюсь.
Непонятно причем здесь два объекта одного класса и разный набор методов. Та утиная типизация, о которой я знаю, выражается в следующем предложении: "Если объект ходит как утка, и крякает как утка, значит он — утка."
Т.е. мы судим по объекту на основании поведения объекта (поддерживаемым методам), а не по его генеалогическому древу (наследование класса/реализация интерфейса). Т.е. если у объекта есть метод [], мы можем работать с ним, как с массивом, хотя это совсем необязательно массив. В целом утиная типизация это скорее соглашение, и следовать этому соглашению можно как при написании кода на PHP, так и на Python или Ruby. Другое дело, что одни языки больше располагают к этому, а другие — меньше.
Занятно, тоже хотел заняться переводом этой статьи :)
Перевод, кстати, отличный! Теперь Вы обязаны перевести продолжение, чтобы полностью раскрыть тему :)
Ну, если быть чуть более точным, во втором абзаце автор упоминает, что после пары лет ковыряния PHP он решил открыть для себя дивный новый мир с ColdFusion, Java, Javascript, etc. Другое дело, что PHP является его основным языком последние 13 лет.
Нравится мне Ваш сатирический подход к изложению :)
Теперь по теме. Давайте отставим эстетику немного в сторону и взглянем на картину в целом. Я думаю мы все понимаем, что не бывает самого лучшего инструмента, бывает инструмент наиболее подходящий для решения поставленной задачи. Именно такой наиболее подходящий инструмент и выберет умный, опытный человек. Однако, часто невозможно выделить самый наиболее подходящий инструмент, обычно имеется некоторое количество оптимальных в том или ином смысле решений (есть даже специальный раздел научный на эту тему — многокритериальная оптимизация).
Проиллюстрирую на примере:
Точки A, B, C и D — являются в некотором смысле оптимальными. Так вот, в разных ситуация какие-то критерии могут быть более приоритетными, какие-то менее приоритетными, именно это и позволяет из множества оптимальных решений выбрать одно единственное, но это не делает другие решения «менее оптимальными» в целом, это делает их менее оптимальными в данной узко-конкретной ситуации.
Так вот, PHP (точка B, например) — хорош, потому что он является самым оптимальным для многих людей и многих ситуациях, но Java (точка C) — тоже хорош, и Ruby (B), и Haskell (A). Просто посмотрите на картину в целом.
Я тоже PHP-шник. И я думаю, что мечты у нас у каждого свои… кроме, разве что, мечты использовать литералы для списков (спасибо 5.4) :)
Касательно моего комментария, он был к тому, чтобы довольно длительное время была мода пинать PHP по поводу и без повода, просто потому что в PHP коммьнити было много непрофессиональных разработчиков. Причем пинали даже те, кто к IT имел мало отношения. Причем в процессе пинания очень часто подменяли понятия, в результате доходя до абсурдного: "<Что-то про PHP> => <На PHP пишут одни говнокодеры> => <PHP — говно>", что имеет мало общего с действительностью.
Сейчас похожая ситуация происходит с Руби и с Рельсами, хотя и Руби и Рельсы на мой взгляд просто замечательные язык и фреймворк, соответственно.
В общем это я к тому, что возможно происходящее заставит людей по новому взглянуть на ситуация и поможет начать выносить адекватные и объективные суждения, а не следовать на поводу у глупых трендов.
P.S. Ну, и я уже устал слышать высказывания в духе «Ты чего, себя не уважаешь?», от разных людей, просто потому, что я в данный конкретный момент пишу на PHP. Хотя помимо PHP я знаю Java, Ruby, Python и немного C++.
Именно для этого нам и даны Pull Request'ы :)
Хотя реализация change может быть несколько затруднительна: все-таки PHP не настолько крут в метапрограммировании как Ruby.
А теперь представьте (немного утрировано), что схема у Вас меняется несколько раз в день, в течение хотя бы полугода, и в команде хотя бы 2 человека, причем каждый может менять схему. Я думаю уже через пару недель у Вас начнутся проблемы, при использовании быстрого и наглядного подхода с SQL-запросами :) Не устанете рассказывать сокаманднику Васе, что и как Вы сегодня поменяли в базе?
На самом деле, кажется что долго с миграциями из-за большого сетапа (относительно). Через некоторое время написание миграции занимает в разы меньше времени, чем использование голого SQL.
Или это Вы к тому, что надо бы примерчик посложнее?
Не уверен, что тут все так просто.
Если данные не интересуют, то это можно просто дропнуть исходную БД, а потом создать заново из дампа целевой. Если все же хотелось бы сохранить какие-то данные, причем не только те, что находятся в «пересечении» атрибутов таблиц исходной и целевой БД, я прямо так сразу и не могу предложить адекватного решения. Например, как отработать такую ситуацию, без какой-либо дополнительной информации?
Была следующая схема у таблицы test, например:
a -> int
b -> string
c -> string
Стала
a -> int
d -> string
e -> string
Где c была переименована в d, а b была переименована в e.
Да, Вы правы, делает то же самое. Но, несмотря на то, что Symfony — замечательный фреймворк, свет на нем клином не сошелся, а с «голой» Doctrine, по-моему не так удобно работать в плане миграций.
Вообще сейчас большая часть современных фреймворков реализует механизм миграций в том или ином виде, и если начинать новый проект, лучше использовать готовую инфраструктуру. Описанное в статье решение — это, на мой взгляд, больше для легаси.
Не совсем понятно, что имеется в виду под «ручным отслеживанием». Если нужно что-то изменить — вместо того, чтобы ручками править БД, напишите миграцию. Если придерживаться этого подхода и не править БД руками!, то все, что нужно будет сделать любому разработчику для приведения продакшена в актуально состояние, это набрать в консоли ./ruckus db:migrate
(за исключением случая очень больших таблиц)
Касательно инструмента, который бы сравнивал схему и самостоятельно генерировал миграционные SQL-файлы, тут достаточно сложный вопрос. Я когда-то использовал Toad for MySQL (если мне не изменяет память), но результаты были иногда просто обескураживающие (в плохом смысле).
Ну, и к тому же, один из пунктов философии Python, если мне не изменяет память — «Явное лучше, чем неявное» ;)
Непонятно причем здесь два объекта одного класса и разный набор методов. Та утиная типизация, о которой я знаю, выражается в следующем предложении: "Если объект ходит как утка, и крякает как утка, значит он — утка."
Т.е. мы судим по объекту на основании поведения объекта (поддерживаемым методам), а не по его генеалогическому древу (наследование класса/реализация интерфейса). Т.е. если у объекта есть метод
[], мы можем работать с ним, как с массивом, хотя это совсем необязательно массив. В целом утиная типизация это скорее соглашение, и следовать этому соглашению можно как при написании кода на PHP, так и на Python или Ruby. Другое дело, что одни языки больше располагают к этому, а другие — меньше.Перевод, кстати, отличный! Теперь Вы обязаны перевести продолжение, чтобы полностью раскрыть тему :)
Теперь по теме. Давайте отставим эстетику немного в сторону и взглянем на картину в целом. Я думаю мы все понимаем, что не бывает самого лучшего инструмента, бывает инструмент наиболее подходящий для решения поставленной задачи. Именно такой наиболее подходящий инструмент и выберет умный, опытный человек. Однако, часто невозможно выделить самый наиболее подходящий инструмент, обычно имеется некоторое количество оптимальных в том или ином смысле решений (есть даже специальный раздел научный на эту тему — многокритериальная оптимизация).
Проиллюстрирую на примере:
Точки A, B, C и D — являются в некотором смысле оптимальными. Так вот, в разных ситуация какие-то критерии могут быть более приоритетными, какие-то менее приоритетными, именно это и позволяет из множества оптимальных решений выбрать одно единственное, но это не делает другие решения «менее оптимальными» в целом, это делает их менее оптимальными в данной узко-конкретной ситуации.
Так вот, PHP (точка B, например) — хорош, потому что он является самым оптимальным для многих людей и многих ситуациях, но Java (точка C) — тоже хорош, и Ruby (B), и Haskell (A). Просто посмотрите на картину в целом.
А касательно списка недостатков, тут на любой язык или технологию при желании можно много чего найти. Вот занятный пример:
Con: lwn.net/Articles/249460/
Pro: www.drdobbs.com/cpp/linus-and-c/229700143
Касательно моего комментария, он был к тому, чтобы довольно длительное время была мода пинать PHP по поводу и без повода, просто потому что в PHP коммьнити было много непрофессиональных разработчиков. Причем пинали даже те, кто к IT имел мало отношения. Причем в процессе пинания очень часто подменяли понятия, в результате доходя до абсурдного: "<Что-то про PHP> => <На PHP пишут одни говнокодеры> => <PHP — говно>", что имеет мало общего с действительностью.
Сейчас похожая ситуация происходит с Руби и с Рельсами, хотя и Руби и Рельсы на мой взгляд просто замечательные язык и фреймворк, соответственно.
В общем это я к тому, что возможно происходящее заставит людей по новому взглянуть на ситуация и поможет начать выносить адекватные и объективные суждения, а не следовать на поводу у глупых трендов.
P.S. Ну, и я уже устал слышать высказывания в духе «Ты чего, себя не уважаешь?», от разных людей, просто потому, что я в данный конкретный момент пишу на PHP. Хотя помимо PHP я знаю Java, Ruby, Python и немного C++.
Хотя реализация change может быть несколько затруднительна: все-таки PHP не настолько крут в метапрограммировании как Ruby.
На самом деле, кажется что долго с миграциями из-за большого сетапа (относительно). Через некоторое время написание миграции занимает в разы меньше времени, чем использование голого SQL.
Или это Вы к тому, что надо бы примерчик посложнее?
Если данные не интересуют, то это можно просто дропнуть исходную БД, а потом создать заново из дампа целевой. Если все же хотелось бы сохранить какие-то данные, причем не только те, что находятся в «пересечении» атрибутов таблиц исходной и целевой БД, я прямо так сразу и не могу предложить адекватного решения. Например, как отработать такую ситуацию, без какой-либо дополнительной информации?
Была следующая схема у таблицы test, например:
Стала
Где
cбыла переименована вd, аbбыла переименована вe.Вообще сейчас большая часть современных фреймворков реализует механизм миграций в том или ином виде, и если начинать новый проект, лучше использовать готовую инфраструктуру. Описанное в статье решение — это, на мой взгляд, больше для легаси.
./ruckus db:migrate(за исключением случая очень больших таблиц)
Касательно инструмента, который бы сравнивал схему и самостоятельно генерировал миграционные SQL-файлы, тут достаточно сложный вопрос. Я когда-то использовал Toad for MySQL (если мне не изменяет память), но результаты были иногда просто обескураживающие (в плохом смысле).