Ну на самом деле Microsoft и так лезет изо всех щелей. Не только на Хабре. Их реклама уже порядком надоела, хотя видимо её всё-таки стараются делать не слишком навязчивой. Т.е. без постоянного маргания и ярких контрастных цветов, как это часто делают на многих других flash-банерах.
В принципе всё очень логично. Если разработчики будут меньше пользоваться продукцией компании она будет менее востребована. Так что Microsoft агрессивно двигает свою продукцию по всем направлениям. Книжки вон уже бесплатно рассылали.
Понятно, что нужно использовать магию. Правда в таком варианте тяжеловато будет делать дополнительную обработку полей. Хотелось бы чего-то более тонкого, хотя это я уже привередничаю. На самом деле конечно 90% задач решается простыми запросами. Но концепт нравится.
Гм. Где-то тут на хабре проскакивала ссылка на перевод статейки в духе «ORM — Вьетнам компьютерной науки». Там очень чётко были разжёваны плюсы и минусы такого подхода. В общих чертах — приходится вместо SQL учить нечто, написаное на языке. Это нечто более громоздко, часто трудно в изучении и при этом часто не даёт нужной гибкости. Алхимия даёт гибкость, но ценой той самой громоздкой монструозности сложных запросов.
Язык запросов максимально преспособлен для написания запросов, ага. ) От Питона я не совсем того ожидаю. Вернитесь к самому посту и посмотрите. Практически SQL, но на самом деле Ruby. А это даёт, как мне кажется, кучу плюшек. Во-первых можно писать сложные запросы без трёхэтажных ORM-конструкций. Во-вторых от автора запроса может быть скрыта львиная часть работы. Всё те же упомянутые валидация, кеширование, преобразование результата в объект. Я думаю что мне было бы удобно пользоваться такой штукой.
На Питоне решение из Джанго меня в принципе устраивает. Алхимия на мой вкус не слишком интуитивно-понятная и слишком громоздкая. Но описаное выше решение было бы близким к идеальному. Конечно до той поры, пока объектные базы не будут работать со скоростью реляционных.
Ну что значит «серьёзнее»? Я в общем то не собираюсь создавать библиотек вселенского масштаба. А для собственного развлечения подойдут и «несерьёзные» поделки.
Зачем вы мне предложили алхимию я так и не понял. Мне то как раз интересно было бы использовать синтаксис максимально приближённый к SQL (чтобы сложные запросы не выглядели монструозно; в sqlAlchemy они страшны даже с использованием одного подзапроса, не говоря о большем), но с дополнительными плюшками, типа валидации введённых данных а-ля поля в Django, кешированием и пр. Пока подобной реализации на Питоне мне не встречалось.
А мне понравилось. Как раз размышлял над возможностью создания аналогичной фишки на Питоне с помощью with. Но там скорее всего всё же посложнее получится.
Весь интерес конечно не в том, чтобы переписать SQL на новый лад, а в перспективе развития. Наверняка можно много чего донавернуть. Автовалидацию полей, кэш, возможно генерацию объектов из результата выборки. По моему это было бы потрясающе удобно. Просто пишешь почти на SQL и всё делается на автомате. Впрочем, на Руби никогда не писал (только игрался немного), так что не скажу, чего вам, рубистам, надо. Верняк сейчас рельсовики скажут, что им ActiveRecord хватает.
Как вам сказать. Лично по-моему то что вы сейчас написали — это как раз попытка реализовать Builder. Так что вы уж определитесь — валить все функции в один класс или использовать этот класс как оболочку, которая генерирует для себя всё необходимое.
Быть в курсе всех методов на большом проекте просто не возможно. Я не найду с ходу такой библиотеки или языка, про которые я мог бы смело сказать «я в курсе всего». Всё забывается, всё разрастается. И крайне не хочется перекапывать весь мануал, если мне понадобится ввести ещё один метод на предмет наличия такого метода в каком-нибудь соседнем классе. Тут никакая wiki не спасёт.
Префиксы пока ещё не монстрообразны? ) А если вам понадобится использовать лазер где-то в другом проекте отдельно от корабля, то придётся писать $laser->laser_heatEmergency()? По-моему это начало моего второго варианта. Через годик появятся префиксы в три этажа.
Проблема проектирования — это я согласен. Но вы, например, можете быть уверены, что завтра заказчик не придёт и не скажет: «Встройте мне вот здесь 2 системы с 3-мя подсистемами и здесь ещё 3»? А возможно и раньше у вас появятся какие-то насущные потребности. Собственно для этого и создавались agile-методы разработки. При постоянно меняющихся требованиях вы должны комфортно себя чувствовать и легко вносить изменения. У вас же получится что любое расширение сведётся к сваливанию дополнительного функционала с гигантский объект. Ваш подход получается более закостенелым. Не зная конкретной задачи я не могу утверждать, что для вас это критично. Но начиная работу над новым абстрактным проектом я бы так делать никогда не стал.
Про проектирование. Если у вас в Builder создаёт сотни объектов, то это дважды неправильное проектирование. Паттернов и методик разных куча. Например, напишите всё в ленивом стиле. Тогдя для того чтобы в запросе дёрнуть лазер вам не понадобится инициализировать двигатель. Вобще я слабо преставляю ситуацию, в которой для обработки запроса приходится инициализировать несколько сотен объектов.
Забавно. Как раз думаю, не написать ли статейку про mro в Питоне.
Вы правы, но я нигде не говорил, что это зло. Всегда говорил, что момент спорный. Просто я к тому, что если в языке нету множественного наследования и есть интерфейсы, то не стоит пытаться впихнуть что-то ещё. С тем же успехом можно пытаться насиловать PHP аспектами, прототипами или функциональным программированием. Будет жутко сложно, медленно, неудобно и непонятно. Если очень хочется чего-то эдакого, то лучше сменить язык.
Мне по мелочи удавалось успешно использовать множественное наследование в Питоне и Перле. Концепт Руби тоже достаточно интересен. Но лично для меня это всё ещё баловство. Интересно, кстати, как сейчас дела с method resolution order в Перле. Очень давно не следил за этим языком. То, как причесали Питон и возможность использовать метаклассы конечно даёт хорошую гибкость. Но как по мне так и путаницы вносится прилично. Впрочем, надо побольше поэкспериментировать.
Мне кажется, что вы сейчас пытаетесь рализовать анти-паттерн God Object. Т.е. вы пытаетесь запихать весь функционал в некий один объект. Если вернуться к примеру из начала вашего поста, то космическому кораблю должно быть до лампочки, какие у него двигатели, батареи, лазер и прочие девайсы. Он должен легко из них собираться и, при необходимости, реактивные двигатели должны легко меняться на ионные без усилий и потери функционала.
Самая плохая идея — засунуть всё в один объект. Если это делается явно, то код становится невозможно сопровождать, т.к. в нём 5 тысяч строк и какие функции с каими связаны — не разобраться. Конечно, вы несколько разрядили ситуацию разнеся эти куски в отдельные файлы. Теперь по крайней мере функции, имеющие друг к другу какое-то отношение сгруппированы. Но остальные проблемы никуда не денутся.
К примеру, останется проблема конфликта имён. Как быть, если у двигателя, лазера и кофеварки есть метод heatEmergency?
Ещё более забавным представляется случай, если создатель кофеварки будет использовать метод heatEmergency, но забудет написать реализацию. Тогда перегретая кофеварка будет способна выключить двигатели на корабле. И не думаю, что эта ошибка будет из ряда очевидных и легко дебагнется. Видимо умными словами это можно назвать нарушением инкапсуляции. Ведь и в принципе любой системе будут доступны методы любой другой системы, что явно не здорово и может привести к трудноуловимым глюкам.
В случае же «множественного наследования» просто можно вешаться. Если в космическом корабле есть грузовой отсек, в котором есть транспортный корабль у которого тоже есть двигатель… Когда всё это сидит в одном объекте методов у него будет миллион. И тут я вижу 2 варианта развития событий. Либо у нас будет ничего не говорящий метод heatEmergency и мы будем гадать, что выключится при его вызове — кофеварка, лазер или двигатели на транспортном корабле. Или появятся моструозные методы, типа mainShip_cargoBay_cargoShip_Engine_heatEmergency и вас будут проклинать все, кому придётся дальше работать с этим кодом. Особенно если придётся использовать CargoShip отдельно от главного корабля.
Вот то, что боле-мене сходу пришло в голову. Как видите, основная проблема будет как всегда в наращивании функционала. К тому же, если вам понадобится перенести в другой проект какую-то крупную часть из этого, то вам придётся руками собирать CargoBay, например, из ошмётков, раскиданных в системе. Т.е. если вам нужен не весь корабль, но некая его полноценная часть в случае использования ООП подхода вы просто возмёте и перенесёте нужные объекты. Конечно, там тоже придётся повозится со связями, но по крайней мере они прописаны в явном виде. Если же в вашем способе всё будет сыпаться в один класс, то выделить нужные куски будет гораздо труднее.
Относительно скорости. Мне как-то слабо верится, что разница в создании N дополнительных классов даёт такую нагрузку. Вы, видимо, используя Builder разносили все классы по отдельным файлам? Если да, то что мешает слить их так же в один файл?
На счёт множественного наследования — спорный вопрос. Обычно считается, что если оно стало критически необходимо (по крайней мере в PHP), то структура не правильно спроектирована. Я, кстати, так и не понял, чем вам обычное наследование не угодило? Если грамотно разделить функционал на связанные куски, то любой child логично наращивает функциональность parent'а. Вместе с интерфейсами и абстрактными классами это даёт достаточную гибкость.
Гм. Это что? Попытка реализации множественного наследования на PHP? Зачем?
В принципе сам факт множественного наследования — один из древнейших предметов для холиваров. Иногда это может быть удобно, но в вашем случае скорее всего стоит поискать альтернативные подходы. Например наследование. По-моему им все вышеозначенные проблемы замечательно решаются. Ещё можете посмотреть в сторону паттерна Builder (http://sourcemaking.com/design_patterns/builder).
Подобное же извращение видел только у ребят, которые пытались на PHP аспектно-ориентированное программирование реализовать. Но они то честно признали, что исхитрились злобным хаком, т.к. по другому просто не получалось. В вашем же случае альтернативы гораздо предпочтительнее.
НЛП, соционика и прочая попсо-психология — это бизнес. Ближайший родственник бизнеса на книжках «99 секретов успеха», «Как разбогатеть за 3 дня» и тому подобных. Практически всё, что широко уходит в массы имеет уровень шаманизма с бубном. Человек ленив и любыит когда всё просто. Не важно правда это или нет. Работает или нет. Главное просто.
Соответственно и уровень / применимость у неё как у школьного паскаля со школьным уровнем знаний. Можно линии рисовать и символы на экран выводит. Или даже два числа сложить. Но не более. Нормальная психология требует уйму времени и практики. Не знаю осталась ли в США ещё традиция, но раньше чтобы считаться психоаналитиком надо было получить медицинское образование, иметь большой клинический опыт (от 5 лет по-моему, может и больше), сдать кучу дисциплин и в конце экзамен комиссии из лучших психоаналитиков современности. Естественно что до 30 лет это никому не удаётся. Зато специалисты действительно хорошие. А «профессиональным» НЛП-шникам, которым от роду 23 года и которые прошли курсы за 3 месяца я как-то мало верю. Не говоря уже о самоучках.
Лучше бы взяли что-нибудь постандартнее. PEAR там покапайте или ещё где. Просто если вам доведётся работать в команде, то ваш чудо-велосипед могут не оценить коллеги. Или того хуже — у них могут быть свои. Проверенные временем сторонние библиотеки очень помогают в некоторой стандартизации. Если бы всем было лень учить чужое и не лень изобретать своё, то сидели бы мы сейчас на деревьях с миллионами разнообразных палок-копалок. Зато у каждого своя.
В целом ваш скрипт просто не приносит видимой мне пользы. По поводу нескольких серверов — можно было бы и ассоциативным массивом проблему решить. Не говоря уже о том, что по хорошему надо выносить данные о подключении в файл конфигов и один раз кинув свой такой файл на каждый сервак благополучно забыть обо всех проблемах.
По поводу получения данных в виде массива. Лучше не надо, если действительно не надо. В 90% случаев приходится работать с записями последовательно. Если опустить подробности и вариации, то в большинстве случаев MySQL сервер отвечает вам «кусками». Т.е. PHP гораздо быстрее получит доступ к первым строчкам в случае большой выборки. И вместо того чтобы тормозить до того момента как все данные придут можно было бы начать их обрабатывать. Ну уж про память я и не говорю. Если выборка большая, то в памяти будет болтаться здоровенный массив. Традиционно проблему решают так: создают методы next и fetchAll. Первый будет просто дёргать mysql_fetch_array для вашего ресурса каждый раз, т.е. позволит начать работу не дожидаясь прихода всех данных. Второй позволит получить массив, если действительно нужен массив. Собственно вы его и написали.
Ещё раз настоятельно рекомендую покопать чужой код. Там часто бывают умные и интересные мысли.
Анонимности в современном мире вобще нет. Да и не нужна она никому. Если кто-то сильно захочет что-то узнать (читай на кону большие бапки) — узнает по любому. А из-за мелочи никто париться не будут. Да и банкам лишний гемор без пользы для себя тоже не нужен.
Всё это конечно интересно, только основная причина отсутствия широкого хода «электронных денег» — отсутствие потребности. Всем и с кредитками уютно живётся, особенно за рубежом. А постоянный мониторинг счёта уже очень много где можно оформить в виде SMS уведомлений. Всё просто, всё удобно. Зачем огород городить?
В принципе всё очень логично. Если разработчики будут меньше пользоваться продукцией компании она будет менее востребована. Так что Microsoft агрессивно двигает свою продукцию по всем направлениям. Книжки вон уже бесплатно рассылали.
Понятно, что нужно использовать магию. Правда в таком варианте тяжеловато будет делать дополнительную обработку полей. Хотелось бы чего-то более тонкого, хотя это я уже привередничаю. На самом деле конечно 90% задач решается простыми запросами. Но концепт нравится.
Язык запросов максимально преспособлен для написания запросов, ага. ) От Питона я не совсем того ожидаю. Вернитесь к самому посту и посмотрите. Практически SQL, но на самом деле Ruby. А это даёт, как мне кажется, кучу плюшек. Во-первых можно писать сложные запросы без трёхэтажных ORM-конструкций. Во-вторых от автора запроса может быть скрыта львиная часть работы. Всё те же упомянутые валидация, кеширование, преобразование результата в объект. Я думаю что мне было бы удобно пользоваться такой штукой.
На Питоне решение из Джанго меня в принципе устраивает. Алхимия на мой вкус не слишком интуитивно-понятная и слишком громоздкая. Но описаное выше решение было бы близким к идеальному. Конечно до той поры, пока объектные базы не будут работать со скоростью реляционных.
Зачем вы мне предложили алхимию я так и не понял. Мне то как раз интересно было бы использовать синтаксис максимально приближённый к SQL (чтобы сложные запросы не выглядели монструозно; в sqlAlchemy они страшны даже с использованием одного подзапроса, не говоря о большем), но с дополнительными плюшками, типа валидации введённых данных а-ля поля в Django, кешированием и пр. Пока подобной реализации на Питоне мне не встречалось.
Весь интерес конечно не в том, чтобы переписать SQL на новый лад, а в перспективе развития. Наверняка можно много чего донавернуть. Автовалидацию полей, кэш, возможно генерацию объектов из результата выборки. По моему это было бы потрясающе удобно. Просто пишешь почти на SQL и всё делается на автомате. Впрочем, на Руби никогда не писал (только игрался немного), так что не скажу, чего вам, рубистам, надо. Верняк сейчас рельсовики скажут, что им ActiveRecord хватает.
Префиксы пока ещё не монстрообразны? ) А если вам понадобится использовать лазер где-то в другом проекте отдельно от корабля, то придётся писать $laser->laser_heatEmergency()? По-моему это начало моего второго варианта. Через годик появятся префиксы в три этажа.
Проблема проектирования — это я согласен. Но вы, например, можете быть уверены, что завтра заказчик не придёт и не скажет: «Встройте мне вот здесь 2 системы с 3-мя подсистемами и здесь ещё 3»? А возможно и раньше у вас появятся какие-то насущные потребности. Собственно для этого и создавались agile-методы разработки. При постоянно меняющихся требованиях вы должны комфортно себя чувствовать и легко вносить изменения. У вас же получится что любое расширение сведётся к сваливанию дополнительного функционала с гигантский объект. Ваш подход получается более закостенелым. Не зная конкретной задачи я не могу утверждать, что для вас это критично. Но начиная работу над новым абстрактным проектом я бы так делать никогда не стал.
Про проектирование. Если у вас в Builder создаёт сотни объектов, то это дважды неправильное проектирование. Паттернов и методик разных куча. Например, напишите всё в ленивом стиле. Тогдя для того чтобы в запросе дёрнуть лазер вам не понадобится инициализировать двигатель. Вобще я слабо преставляю ситуацию, в которой для обработки запроса приходится инициализировать несколько сотен объектов.
Вы правы, но я нигде не говорил, что это зло. Всегда говорил, что момент спорный. Просто я к тому, что если в языке нету множественного наследования и есть интерфейсы, то не стоит пытаться впихнуть что-то ещё. С тем же успехом можно пытаться насиловать PHP аспектами, прототипами или функциональным программированием. Будет жутко сложно, медленно, неудобно и непонятно. Если очень хочется чего-то эдакого, то лучше сменить язык.
Мне по мелочи удавалось успешно использовать множественное наследование в Питоне и Перле. Концепт Руби тоже достаточно интересен. Но лично для меня это всё ещё баловство. Интересно, кстати, как сейчас дела с method resolution order в Перле. Очень давно не следил за этим языком. То, как причесали Питон и возможность использовать метаклассы конечно даёт хорошую гибкость. Но как по мне так и путаницы вносится прилично. Впрочем, надо побольше поэкспериментировать.
Самая плохая идея — засунуть всё в один объект. Если это делается явно, то код становится невозможно сопровождать, т.к. в нём 5 тысяч строк и какие функции с каими связаны — не разобраться. Конечно, вы несколько разрядили ситуацию разнеся эти куски в отдельные файлы. Теперь по крайней мере функции, имеющие друг к другу какое-то отношение сгруппированы. Но остальные проблемы никуда не денутся.
К примеру, останется проблема конфликта имён. Как быть, если у двигателя, лазера и кофеварки есть метод heatEmergency?
Ещё более забавным представляется случай, если создатель кофеварки будет использовать метод heatEmergency, но забудет написать реализацию. Тогда перегретая кофеварка будет способна выключить двигатели на корабле. И не думаю, что эта ошибка будет из ряда очевидных и легко дебагнется. Видимо умными словами это можно назвать нарушением инкапсуляции. Ведь и в принципе любой системе будут доступны методы любой другой системы, что явно не здорово и может привести к трудноуловимым глюкам.
В случае же «множественного наследования» просто можно вешаться. Если в космическом корабле есть грузовой отсек, в котором есть транспортный корабль у которого тоже есть двигатель… Когда всё это сидит в одном объекте методов у него будет миллион. И тут я вижу 2 варианта развития событий. Либо у нас будет ничего не говорящий метод heatEmergency и мы будем гадать, что выключится при его вызове — кофеварка, лазер или двигатели на транспортном корабле. Или появятся моструозные методы, типа mainShip_cargoBay_cargoShip_Engine_heatEmergency и вас будут проклинать все, кому придётся дальше работать с этим кодом. Особенно если придётся использовать CargoShip отдельно от главного корабля.
Вот то, что боле-мене сходу пришло в голову. Как видите, основная проблема будет как всегда в наращивании функционала. К тому же, если вам понадобится перенести в другой проект какую-то крупную часть из этого, то вам придётся руками собирать CargoBay, например, из ошмётков, раскиданных в системе. Т.е. если вам нужен не весь корабль, но некая его полноценная часть в случае использования ООП подхода вы просто возмёте и перенесёте нужные объекты. Конечно, там тоже придётся повозится со связями, но по крайней мере они прописаны в явном виде. Если же в вашем способе всё будет сыпаться в один класс, то выделить нужные куски будет гораздо труднее.
Относительно скорости. Мне как-то слабо верится, что разница в создании N дополнительных классов даёт такую нагрузку. Вы, видимо, используя Builder разносили все классы по отдельным файлам? Если да, то что мешает слить их так же в один файл?
На счёт множественного наследования — спорный вопрос. Обычно считается, что если оно стало критически необходимо (по крайней мере в PHP), то структура не правильно спроектирована. Я, кстати, так и не понял, чем вам обычное наследование не угодило? Если грамотно разделить функционал на связанные куски, то любой child логично наращивает функциональность parent'а. Вместе с интерфейсами и абстрактными классами это даёт достаточную гибкость.
Хотя в случае с кораблём конечно нужен Builder.
В принципе сам факт множественного наследования — один из древнейших предметов для холиваров. Иногда это может быть удобно, но в вашем случае скорее всего стоит поискать альтернативные подходы. Например наследование. По-моему им все вышеозначенные проблемы замечательно решаются. Ещё можете посмотреть в сторону паттерна Builder (http://sourcemaking.com/design_patterns/builder).
Подобное же извращение видел только у ребят, которые пытались на PHP аспектно-ориентированное программирование реализовать. Но они то честно признали, что исхитрились злобным хаком, т.к. по другому просто не получалось. В вашем же случае альтернативы гораздо предпочтительнее.
Соответственно и уровень / применимость у неё как у школьного паскаля со школьным уровнем знаний. Можно линии рисовать и символы на экран выводит. Или даже два числа сложить. Но не более. Нормальная психология требует уйму времени и практики. Не знаю осталась ли в США ещё традиция, но раньше чтобы считаться психоаналитиком надо было получить медицинское образование, иметь большой клинический опыт (от 5 лет по-моему, может и больше), сдать кучу дисциплин и в конце экзамен комиссии из лучших психоаналитиков современности. Естественно что до 30 лет это никому не удаётся. Зато специалисты действительно хорошие. А «профессиональным» НЛП-шникам, которым от роду 23 года и которые прошли курсы за 3 месяца я как-то мало верю. Не говоря уже о самоучках.
Лучше бы взяли что-нибудь постандартнее. PEAR там покапайте или ещё где. Просто если вам доведётся работать в команде, то ваш чудо-велосипед могут не оценить коллеги. Или того хуже — у них могут быть свои. Проверенные временем сторонние библиотеки очень помогают в некоторой стандартизации. Если бы всем было лень учить чужое и не лень изобретать своё, то сидели бы мы сейчас на деревьях с миллионами разнообразных палок-копалок. Зато у каждого своя.
В целом ваш скрипт просто не приносит видимой мне пользы. По поводу нескольких серверов — можно было бы и ассоциативным массивом проблему решить. Не говоря уже о том, что по хорошему надо выносить данные о подключении в файл конфигов и один раз кинув свой такой файл на каждый сервак благополучно забыть обо всех проблемах.
По поводу получения данных в виде массива. Лучше не надо, если действительно не надо. В 90% случаев приходится работать с записями последовательно. Если опустить подробности и вариации, то в большинстве случаев MySQL сервер отвечает вам «кусками». Т.е. PHP гораздо быстрее получит доступ к первым строчкам в случае большой выборки. И вместо того чтобы тормозить до того момента как все данные придут можно было бы начать их обрабатывать. Ну уж про память я и не говорю. Если выборка большая, то в памяти будет болтаться здоровенный массив. Традиционно проблему решают так: создают методы next и fetchAll. Первый будет просто дёргать mysql_fetch_array для вашего ресурса каждый раз, т.е. позволит начать работу не дожидаясь прихода всех данных. Второй позволит получить массив, если действительно нужен массив. Собственно вы его и написали.
Ещё раз настоятельно рекомендую покопать чужой код. Там часто бывают умные и интересные мысли.