PHP — отстой! Но я люблю его!

http://blog.ircmaxell.com/2012/04/php-sucks-but-i-like-it.html
  • Перевод
Буквально вчера я прочёл весьма занимательный пост PHP: a fractal of bad design (русский вариант на хабреприм. перев.). Этот неоднозначный и провокационный топик широко обсуждается всем PHP-сообществом. Честно говоря, там есть как действительно хорошие позиции и замечания, так и откровенные ошибки, не позволяющие увидеть всю картину в целом.


Небольшие ошибки


В посте достаточно много ошибок и вообще автор путает божий дар с яичницей. Позвольте мне выделить главные:
  • Нет отладчика – в PHP есть xdebug, который великолепно работает как интерактивный отладчик.
  • Нет поддержки тредов – это так, но он отмечает это за недостаток, когда я нахожу это положительным; потому как жизненный цикл приложения начинается с запроса (я раскрою этот тезис чуть более подробно)
  • == бесполезен – да нет, он весьма полезен, если использовать его правильным образом. Да, я соглашусь, что использую его всё меньше и меньше, но когда он вам нужен – он полезен…
  • Проблемы видимости с глобальными переменными – он находит в этом нечто диковинное. Честно говоря, по мне это одна из тех вещей, в которых PHP превосходит практически все другие языки. Если вы не видите global $var внутри какого-то блока, вы знаете, что переменная локальная. Поэтому просто посмотрев на декларацию функции, вы немедленно можете оценить, какое должно быть внешнее окружение без отслеживания каждой отдельной переменной (и не просите вашу IDE сделать это для вас).
  • Константы определяются с помощью вызова функции – это так, но автор забывает о синтаксисе `const FOO = «bar»;`, который является валидным и не является вызовом функции.
  • Статические переменные внутри методов экземпляра глобальны – это правда, потому что это именно то, для чего они предназначены. В Python мы бы использовали `obj.__class__.varname`…
  • PHP привязан к Apache – это откровенная чушь: существует куча приложений, которым Apache не нужен. Просто Apache на большинстве платформ по умолчанию конфигурируется с mod_php. Но по мне, настройка nginx+FastCGI гораздо легче, нежели настройка mod_php под Apache.
  • Нет простого способа «отделить» PHP-приложение и его зависимости от остальной системы – это неправда, так как есть suphp и FastCGI; это ведь действительно просто запустить несколько различных инстансов PHP, работающих на разных версиях. Да, в самом деле, с mod_php вам придётся разделять инстансы Apache, но есть и другие способы организации сервера, нежели mod_php, так что это не совсем честно – списывать на PHP ограничения Apache.
  • Секция особенностей – вот с этого момента я потерялся. Вплоть до этого он говорил об особенностях языка (и с большинством я бы согласился). Но с этого места начинается разговор о библиотеках и фреймворках. Да, в PHP нет системы шаблонов. Но разве есть она в Python или Ruby? В Django и Ruby On Rails есть, а как же тогда Zend и Symfony? В PHP нет XSS-фильтра, но ведь их нет и в Python и Ruby, лишь в фреймворках. PHP не поддерживает роутинг, но разве Python и Ruby поддерживают? Зато есть dev server. И поддержка интерактивного отладчика (xdebug). И такая же ерунда с вопросами безопасности.

В-общем, из всего большого поста, пунктов, которые действительно могут вызвать недовольство, мало. Там написано весьма много, но с таким напыщенным стилем это не очень приятно чтиво.

Мой взгляд



На самом деле с большинством написанного я соглашусь. PHP – противоречив. Многословен. Там действительно есть примеры неадекватного поведения. У него есть много проблем. Порой он уродлив. Иногда он неуклюж в обиходе. Многое оставляет желать лучшего.

Но в то же время он необычайно мощный. Легко и просто можно написать работающее приложение. Действительно легко создать масштабный проект. Несложно его расширять. И что по-настоящему просто – это получить помощь (в Интернете вас поддержит одно из крупнейших и самых активных программистских сообществ).

Однако, есть одна вещь, которая не добавляет языку популярности: возможность использования не-разработчиками. Просто взгляните вокруг на опен-сорсные веб-проекты и вы поймёте, что PHP – это победа. Я имею в виду весь этот рынок CMS, на котором к PHP конкуренты просто не подберутся и на пушечный выстрел (Wordpress, Joomla!, Drupal, vBulletin, MODx, TYPO и т. д.). Посмотрите на любой сетевой рынок услуг, и PHP будет там доминировать (или просто иметь сильнейшее влияние). Всё дело в том, что развернуть PHP-сайт до смешного просто. Так просто, что даже не-разработчики могут это сделать.

Как говорит Brandon Savage: It's About The Customer (А кто клиент?). И это – тот большой кусок пирога, который был упущен в оригинальном посте. В самом деле, с точки зрения разработчика в PHP чего-то не хватает. Но с каких пор разработчик определяет что успешно? Если бы разработчик это определял, то софт типа Wordpress, jQuery и Jenkins/Hudson не достигли бы такого успеха (ибо их исходные коды под характерным вопросом качества). Но они достигли, потому что решают проблему и решают её хорошо.

Всё дело в том что у PHP есть много преимуществ над другими языками. Вот лишь то, что всплыло у меня в голове:
  • HTTP – это объект первого класса. Никакие другие популярные языки этого не предоставляют. Ни Python, ни Ruby, ни C, ни JavaScript. В PHP встроена поддержка HTTP на низком уровне. Вы можете поспорить, что это не так оптимально, но это первый класс. Вам не надо никаких библиотек или фреймворков, чтобы говорить на HTTP.
  • SAPI — это объект первого класса (Server API, mod_php vs CGI vs FastCGI, etc). Это означает то, что PHP разрабатывался так, чтобы быть за плечами более сильного сервера. Также это означает то что передача кода от CLI к API сервера – тривиальна (надо просто посмотреть, как получаются переменны запроса). Нет никакой необходимости использовать библиотеки или фреймоворки, чтобы взаимодействовать с сервером. WSGI в Python в принципе не зря ест свой хлеб, но по-прежнему вам надо подключить библиотеку для общения с сервером. Это делает PHP весьма простым для построения фундамента web-приложений.
  • Цикл жизни приложения от запроса к запросу. В оригинальном посте это было отмечено как негативный аспект. Каждый новый запрос запускает заново PHP (ну, не весь PHP, а ваше PHP приложение) Это хорошая штука, так как (цитата по Rasmus Lerdorf, создатель PHP в интервью) «The shared-nothing architecture of PHP… leads to infinite horizontal scalability in the language itself.» (дословно: «Не позволяющая ничего шарить архитектура PHP … ведёт к бесконечной горизонтальной масштабируемости языка как такового»).
  • Просто громадная база пользователей. Да, и у других языков есть куча последователей, но никто и близко не подбирается к PHP. И лично я думаю, что это – наиболее значимый аспект из всех. Это ковчег, полный знаний о том, как расширить PHP и как решить почти любую проблему. Если вы знаете, что вы делаете, то вы всё, что надо, найдёте.


Этих 4 причин для меня достаточно, чтобы считать PHP моим основным языком. Я знаю и активно применяю Python и серверный JS (node.js в настоящее время), да и знаком ещё с несколькими языками. Но я по прежнему придерживаюсь и буду придерживаться PHP для своих основных проектов, потому что хотя он и не безупречен, он работает…

А ваши мысли?
Поделиться публикацией
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама
Комментарии 605
  • –28
    PHP — хороший язык. Интеграция в html у него лучше чем у любого другого языка (кроме javasript и vb). Правда относится к нему хорошо я стал только после того, как перестал его использовать для серьезных проектов. Со временем остаются только хорошие воспоминания.
    • +52
      >>Интеграция в html

      что?
      • +18
        Как непрограмист могу сказать что если человек и выразился неправильно, по сути он прав — как включить php-код в html-страничку знают все, а как запустить на своём хостинге скрипты написанные на Ruby, Питоне, Перле и пр. — далеко не все. Это я перечислил популярные интрпертируемые языки, а ведь кто-то и на С++ веб-приложения пишет.
        Если что не так написал, просьба пояснить, а не минусовать, goto строка 1
        • –4
          Пхп просто самый распространенный. «Интеграция в html», если можно так выразиться, у пхп как раз дохлая и заключается в банальном выводе переменных через echo. Я бы не назвал это интеграцией.
          Так везде можно.
          Ну и для, например, питона есть много разных шаблонизаторов.
          Равно как и для пхп есть, к примеру, smarty.
          • +16
            У слову пхп сам по себе шаблонизатор.

            Сейчас <?=date('Y')?> год
            


            Мне кажется именно это имелось ввиду под словами «Интеграция в html у него лучше»
            • 0
              У меня двойственное отнощение к short tags. C одной стороны, это удобно. С другой, не рекомендуется к применению, особенно если не известно заранее, где может развертываться приложение.
              • +5
                С выходом 5.4 можно писать <?= $var ?> без включенной директивы short_open_tags
                • +19
                  Да ладно, везде где пишут о short tags, там же пишут о том, что мол лучше им не пользоваться, потому что «не известно заранее, где может развертываться приложение». Как по мне, то обращать внимание на такую вещь не нужно (если, конечно, вы не разрабатываете wordpress или еще что-то суперюзерфрендли). Вы ведь не будете думать что вот мол, не буду писать на utf-8, мало ли у кого-то сервак на cp1251 заточен. Или, допустим, не буду включать вот этот гем в свой rails проект, потому что он под винду не компилится (да и вообще может у юзера gcc в линуксе отсутствует).

                  Согласитесь же, что <?= "" ?> куда более сексуально, чем <?php echo "" ?>
                  :)
                  • +1
                    Хотя конечно с кодировкой сравнение некорректное.
                    • 0
                      Соглашусь, но уже приучил себя к полному варианту)
                  • +3
                    о, а подсветочка-то все-таки хромает :)
                    • 0
                      Это же просто сокращенная форма записи <?php echo ?>… От того что оно на 7 символов короче пхп не становится сразу круто интегрированным в хтмл)
                      Как по мне так наличие в питоне встроенного полноценного шаблонизатора обеспечивает куда лучшую интеграцию.
                      • +2
                        Да я вообще никак не хотел акцентироваться на сокращенной записи:) Да хоть на 20 длиннее.

                        Смысл в другом — пхп-скрипт это шаблон. Весь текст (а обычно это хтмл) из него напрямую перенаправляется браузеру, пока не встретятся тэги <?php, <?.. То что внутри этих тэгов — это логика шаблона, код оттуда интерпретируется, он также может возвращать данные, которые будут отправлены браузеру, а может и не возвращать.

                        Мне кажется, что это можно назвать «круто интегрированным в хтмл» :)

                        Про питон — я не писал скрипты для вэба на голом питоне (и других языках), поэтому про интегрированность в хтмл их, я сказать ничего не могу. Но сдается мне, что там все несколько иначе:)
                        • 0
                          Питон без использования шаблонизаторов, в том числе и встроенных — это будет просто .py файлик который через print выводит весь хтмл код целиком.

                          Но смысла так делать совсем нету, для питона есть вагон разных шаблонизаторов на любой вкус и они очень удобные.
                          Собственно для пхп шаблонизаторы тоже есть, но при них я ничего такого хорошего сказать не могу, тот же Smarty мне как то совсем не понравился.
                          • 0
                            Smarty — не айс. Смотрите «Twig»
                            • 0
                              По иронии, Twig — слизали с питоновского django шаблонизатора 1 к 1 =)
                              • +1
                                Ну вот и славно. Значит в обоих языках есть отличные шаблонизаторы!
                                • 0
                                  К чему ирония, если об этом в README написано?
                                  • 0
                                    Ну тут беседа идёт python vs php в каком то смысле и выяснилось что лучший шаблонизатор тот который сделали питонисты.
                    • +2
                      А зачем в программировании такие люди? Которые кроме на работу с echo ни на что не способны?
                      • +1
                        Спросите у людей, которые платят им деньги. Есть спрос — предложение появится.
                        • –1
                          Спрос на низкокачественных программистов? Нет, ну ок, хорошо что эту нишу заняло php.
                          • +1
                            Спрос на дешевых. И с этой ниши PHP вытесняют, но пока массового перелома в сознании заказчиков не произошло.
                            • –1
                              Да и слава богу, пусть дешевые php программисты, не понимающие вообще ничего, не использующие ar или шаблонизатор дальше клепают сайты визитки. По сути все идет как надо :)
                              • +1
                                А как быть дешевым, использующим AR (хотя DM+UoW больше нравится) и Smarty/Twig?
                                • 0
                                  К таким я могу относится как к людям, вы, собственно говоря — тоже.
                                • +8
                                  Ruby — пузырь. Ставки по сравнению с PHP аналогичного уровня x2, а то и X3 непонятно почему, если на нем и писать легче и все такое.

                                  Потому многие на него и переходят, как только уровень позволит. А это, обычно, происходит раньше, чем человек осилил нормальные фреймворки на php и полноценно использует хотя бы PHP 5.3.

                                  Вот и получается, основными аргументами в пользу Ruby приводят фичи Rails, типа «смотрите тут можно запросы не писать, а так по модному метод класса вызвать». Все это, даже то, чего не было до Rails, уже давно перетащили в PHP-фреймворки. Да, шок: и роуты и орм реализованы и на других языках.

                                  На мой взляд, грамотные аргументы в пользу Руби должны выглядеть примерно так:
                                  — наверное, самый большой набор инструментов для работы с ООП, который даже вводит ряд новых приемов по организации структуры классов
                                  — согласованный и лаконичный синтаксис
                                  — многопоточность

                                  Но никак не «на PHP одни быдлокодеры».
                                  • 0
                                    Ну в целом я с вами согласен. Не очень ясно про рейты и как вы сранивали кондидатов, но я не буду уточнять.
                                    • –4
                                      Пузырь?! Чего вдруг пузырь? Вот скажите мне: хоть 1 из 10 пхп-программистов пишет тесты? Вряд ли больше. Ну и раз речь зашла о пхп-фрейворках, то почему-то многие усиленно стараются быть похожи/копируют рельсы. С чего бы это?

                                      Да ну и сам руби хорош хотя бы за вот такие конструкции: (1..10).inject(:+)
                                      И кучи чего ещё.
                                      • НЛО прилетело и опубликовало эту надпись здесь
                                        • 0
                                          Во-первых, рельсы не есть руби
                                          Во-вторых, рельсы действительно хорошая идея (-:

                                          Иначе бы её не копировали бы.
                                          • НЛО прилетело и опубликовало эту надпись здесь
                                            • –1
                                              Ну расстреливать никого не надо в любом случае (-:
                                              • –1
                                                Используйте аналоги. (на php)
                                                • НЛО прилетело и опубликовало эту надпись здесь
                                          • +2
                                            Вот почему ruby разработчик начального/среднего уровня стоит на рынке дороже php того же уровня? Если порог вхождения ниже, код пишется проще и быстрее, фреймворки гениальны и т. п.? Работать выходит проще, а платят больше?
                                            • 0
                                              Отвечу словами Matz-а: Я не знаю ни одного безработного ruby-программиста (-:
                                              А если есть много безработных пхп-программистов, то зачем платить больше?!
                                              • +5
                                                Мне вот всё равно писать на незнакомом php-фреймворке или на RoR/Django. Но для RoR я недоквалифицирован, а для PHP перквалифицирован на уровень ЗП ~800-1000 у.е. (Питер). На RoR требуют BDD, а на PHP не хотят слышать о TDD, например. На RoR требуют git (да ещё аккаунт на gihub зачем-то), а я к Mercurial привык, а работодатели так вообще VCS не используют.

                                                Могу я считать себя безработным ruby-программистом? :)
                                                • +1
                                                  Как говорят у нас в Одессе, запретить я Вам этого не могу (-:

                                                  Лично я просто не приемлю крайностей: пхп-руби-питон или там виндоус-линукс и т.п.
                                                  В web-программировании уж так заведено, что знать просто один язык невозможно, как мне видится.
                                                  • +1
                                                    Вне спора о качествах того или иного решения (было время, я коммитил в PHP и активно поддерживал его документацию), я отвечу на оба вопроса.

                                                    Платят больше потому, что рубистов – меньше. А меньше их потому что порог вхождения в рельсы больше. Я не раз видел округлившиеся глаза человека, которому рассказывали про ассеты, кофи, сасс и хамл. Хотя ничего, привыкают. Другая проблема с порогом вхождения – другая религия, касающаяся циклов разработки. В мире руби совсем иной подход к BC. Это подстегивает и заставляет быть более социальным и быстрым. И это развивает. Либо люди уходят. Уровень ruby-разработчиков по этой причине растет быстрее, либо скатывается в 0. Сообщество заставляет их учиться, а не дает возможность, как в случае с PHP.

                                                    Аккаунт на гитхабе нужен по описанной выше причине – это способ взаимодействия с этим сообществом. Большая часть рубистов, с которой мне доводилось работать, хоть в каком-нибудь опен-сорсе да поучавствовали. Если не свое корыто, так чужое подлатали. Гитхаб – история взаимодействия с сообществом, которая для рубистов ОЧЕНЬ важна. Это – показатель перспективности и живости. А перспективность, ивость, другими словами потенциал, – самая важная характеристика разработчика. Выучить можно любой язык.

                                                    Я никаким образом не объясняю этим, что руби – лучше. Мое _личное_ мнение на этот вопрос следующее: PHP должен быть вытеснен Groovy или чем-то подобным. Потому что он усиленно растет в Яву, а Ява форкается в то, что похоже на PHP. Факт в том, что вторых младенцев карма и архитектура в разы лучше.
                                                    • 0
                                                      Попытки использовать хамл или *сс я делаю и в пхп, но получается только в тех, которые под контролем vcs (обычно mercurial) и capistrano. Но к этим приложениям особых требований нет, я их сам формирую и могу себя убедить в их полезности. Заказчиков не могу. Ну не понимают они, что сайт им я сделаю за 100 рублей в час, а для малейшего изменения вёрстки придётся искать верстальщика, который возьмёт 200…
                                                      • 0
                                                        Времени правки займут меньше. Более дорогие специалисты, использующие новые технологии, работают быстрее. В этом их смысл. Если это не так, либо специалисты плохие, либо технологиям грош-цена, либо это какой-то специфический случай.

                                                        Это, правда, не отменяет проблемы необходимости минимального распространения. Конкретно у хамла с этим большие проблемы.
                                                        • 0
                                                          Займёт правка час или два не суть для моих заказчиков. Их интересует конечная цена. Мне тоже по сути всё равно, даже интересней когда два часа займёт (за те же деньги).
                                                          • 0
                                                            Меньше денег – меньше ставка. Разве не логично?

                                                            P.S. мои сообщения личные пришли?
                                                • –1
                                                  Даладно? От рубиста начального уровня требуют понимания ООП и метапрограммирования. От php-иста начального уровня понимания echo?
                                                  • 0
                                                    Формально обычно требования одни в вакансиях (кроме нюансов), но от рубистов уже на собеседованиях выясняется, что знание инфраструктуры (ака экосистемы) подразумевается, а не только языка/фреймворка. Спросят невзначай «какие гемы для авторизации лучше использовать?» и ответ «я гемы не использую, работаю с исходниками с гитхаба» не устраивает.
                                                  • 0
                                                    Расскажу историю. Есть у меня знакомый, у него небольшая веб-студия. Распиарил я ему рельсы, написал для него сайт студии небольшой за пиво (для друга же :). Рельсы ему понравились, мол быстро и т.д. После этого он общался с начальником отдела разработки одного крупного новосибирского сайта (они там на php пишут) и спросил: «А как с руби/рельсами у вас дела обстоят»? Он ему ответил, что руби вообще какой-то непонятный язык, да и разработчики на RoR хотят больше денег, чем php'шники. Вот так :)

                                                    Сам на рельсах пишу, в Новосибе вакансий вообще нету (или я где-то не там ищу). Поэтому приходится с зарубежниками работать. И тут возникает некая конкуренция: за рубежом платят больше, чем в среднем по России. Значит, если в России работать, то хочется зарплату не ниже. Возможно еще и поэтому многие рельсовики требуют зарплату больше.
                                                  • +7
                                                    Пузырь, потому, что язык распиарили, а специалистов под него недостаточно.

                                                    На Ruby, тоже, хватает некомпетентных программистов. Нет, конечно, новичков в программировании относительно мало, плюс все сразу с Rails начинают, а не с устаревших говно-CMS, где файлы по 2к строк без единой фукнции, не говоря уже о классах. Еще там сразу git, тесты и другие строгости.
                                                    Но видел уже разное, хотя опыт и минимальный.

                                                    Rails хороший фреймворк, кто спорит? Я о том и говорю, что на PHP есть фреймворки со скопированной идеологией, есть более строгие с хорошо проработанным ООП, есть упрощенные, любой на выбор. И я говорю о качественные MVC-фреймворках с ORM и аналогом роутов.

                                                    Если отбросить нюансы, что как язык Ruby лучше PHP, глупо это не признавать. Но, на мой взгляд, уже не настолько, что бы перевешивать плюсы инфраструктуры PHP, которые только укрепились.
                                                    • 0
                                                      Да никто ничего не пиарит, я особенно и не замечаю (-:

                                                      Закрепилась не инфраструктура, а стереотипы. 9 из 10 студий предложат сайт на пхп. Потому что другого в наличии нет, а на 500$ всегда можно взять студента.

                                                      И не высок/низок порог вхождения в руби/пхп, а порог развёртывания приложения и количество недорогих хостеров. Вот большинство и идёт по пути наименьшего сопротивления: побыстрее нагенерить всякой лабуды и запихнуть в биржи ссылок.
                                                      • 0
                                                        А студент, знающий ruby, за 500 уже не пойдёт?
                                                        • 0
                                                          Согласен, с числом погорячился (-:
                                                        • +2
                                                          Владельцы программистских контор пиарят RoR, что бы обосновать завышенные зарплаты (и свои проценты) своим заказчикам.

                                                          В общем, для меня это выражается в том, что уже не один PM мне говорил, что на RoR разработка в разы быстрее, код не получится плохим и его сможет поддерживать любой программист, итд итп. На вопросы как и почему, ничего внятного не отвечают, в лучшем случае что-то очень общее про гемы и ORM скажут.

                                                          Я готов поверить, что лет так 7 назад, когда Rails только набирал обороты он был единственным веб-фреймворком современного типа и действительно давал существенный прирост в разработке. Но даже если так, то информация уже сильно устарела.

                                                          Да многие, идут по пути наименьшего сопротивления и в данном случае, на мой взгляд, это оправдано.
                                                          • 0
                                                            Ну я не знаком с владельцами, которые пишут только на рельсах. Чаще скорее наоборот: только на пхп.

                                                            Видите ли, в чём ещё дело… в мире руби рельсы — это 98% от всех используемых фреймворков. есть другие, но они не стоят даже рядом. Поэтому рельсы — это как стандарт. Практически любой рубист откроет проект на рельсах и легко разберётся.

                                                            В пхп слишком велико разнообразие фреймворков… Я не говорю, что они плохие, просто они разные. И различие между Zend, Yii или там CI достаточно велико. Это не хорошо и не плохо, это просто факт. И при переключении с одного фреймворка на другой не знакомый будет некоторая задержка.
                                                      • 0
                                                        Имхо, вообще сомнительно, что сильно больше чем 1 из 10 программистов пишет тесты… И не факт, что это плохо…
                                                      • –2
                                                        Потому многие на него и переходят, как только уровень позволит. А это, обычно, происходит раньше, чем человек осилил нормальные фреймворки на php и полноценно использует хотя бы PHP 5.3.

                                                        любой фреймворк — это жертва производительностью в угоду удобству и фичам. чем больше фич — тем более это заметно на производительности.

                                                        и если для того, чтобы нормально программировать на языке X нужны фреймворки — это плохой язык.
                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                          • 0
                                                            Для PHP не нужны, он сам микрофреймворк по сути. Важность этого факта уменьшается, но до ноля ещё далеко.
                                                            • 0
                                                              что вы подразумеваете «для веба»?

                                                              вот серверную часть простенького чатика на php сколько времени вы будете писать? чатик выбран как частный случай ситуации, когда у вас, допустим, 8к клиентов и им всем надо разослать идентичные данные(это может быть и сервис с курсами валют/пробки итп).
                                                              • 0
                                                                А есть (с точки зрения написания) большая разница писать на php, python или C чатик (если не пользоваться многопоточностью)? Так же слушаем сокет, также его обрабатываем.
                                                                • 0
                                                                  >Так же слушаем сокет, также его обрабатываем.

                                                                  отличное описание! 99% протоколов с логикой запрос/ответ попадают под это определение.
                                                                  не стесняйтесь, раскройте мысль, потаённую в «обрабатываем».
                                                                  давайте даже упростим: события(и сообщения) генерирует само приложение.
                                                                  • 0
                                                                    Ну я же не знаю протокол чатика :) Но суть одна и та же — биндинги к сокетным функциям ОС.

                                                                    Про «упростим» немного не понял. В каком виде получаем сообщения? Нужна ли чатику работа с тормозными функциями типа работы с БД или ФС? Блокировки ресурсов и т. п.?

                                                                    Кстати, простенький чатик делается вообще через авторефреш страницы и тут уже совсем без разницы на чём его делать. PHP вон пишут выдерживает 800 rps (правда железо не описано).
                                                                    • 0
                                                                      >Про «упростим» немного не понял. В каком виде получаем сообщения?

                                                                      допустим, раз в секунду рассылать всем подключенным клиентам json вида:
                                                                      {«time»:«unix_timestamp», «connected»: число_клиентов_онлайн }

                                                                      • 0
                                                                        Вариантов много, от написания своего веб-сервера до авторефреша страницы браузере, а страницу через apache+cgi отдавать. Количество клиентов онлайн можно хранить в локальном контексте сервера, а можно на удаленном сервере и изменять/получать через SOAP.

                                                                        Принципиальной разницы на чём это писать не вижу, разве что в некоторых языках это может оказаться в стандартной либе, а в некоторых сторонние придётся подключать.

                                                                        Другое дело, если по каким-то причинам использовать cgi не следует :)
                                                                        • 0
                                                                          >Количество клиентов онлайн можно хранить в локальном контексте сервера, а можно на удаленном сервере и изменять/получать через SOAP.

                                                                          а можно просто в мемкеше держать и через incr/decr менять :)))

                                                                          >Другое дело, если по каким-то причинам использовать cgi не следует :)

                                                                          например по той, что изначально упомянуто 8к клиентов онлайн, т.е. у вас 8к файловых дескрипторов на которых вы ждёте какие-то события.

                                                                          если же рефрешить страничку, допустим, 1 раз в секунду — это 8к rps, на котором cgi так же умрёт.

                                                                          если же взять не json, а google protobuf, то можно хорошо сэкономить на трафике. Вот только весь профит бинарного протокола будет сведён на ноль http-заголовками в варианте с рефрешем.
                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                  • 0
                                                                    ну тут упоминали facebook и проекты с высокой посещаемостью.
                                                                    и вроде как на дворе мир web2.0 с реалтаймом.
                                                                    websockets есть уже почти везде, на подходе webRTC.

                                                                    а странички с посещаемостью полчеловека в минуту писать можно на чём угодно.
                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                                      • 0
                                                                        Автор исходной статьи пишет, что при достаточно высокой квалификации грабельки, заботливо положенные авторами языка можно объезжать.

                                                                        В facebook было написано много кода на php и когда возникли сложности с производительностью, как я понимаю, дешевле оказалось изобрести hiphop, нежели переписывать и переучивать имеющийся штат разработчиков.

                                                                        Всё, опять же, сводится к правильному инструменту под задачу. Беда php в том, что уж очень много задач, для которых есть инструменты лучше.

                                                                        Например, много ли вы знаете серверов трансляций на php?

                                                                        на эрланге есть erlyvideo, на python — flumotion (да и я писал свой сервер для онлайн трансляции — 19к онлайн-клиентов на тестах было. написано на python).
                                                                        • 0
                                                                          Но эти задачи не самые распространенные (в количестве постановок). И я не думаю, что будет хорошей идеей (для меня) говорить работодателю, что, скажем, ему нужно нанимать python-программиста вместо меня. Да покупать (v)DS вместо шареда, да ещё грамотного админа в комплекте. Действительно, мне «дешевле» «изобрести» hiphop.
                                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                                            • 0
                                                                              Переход на питон и джангу для среднего пхп-разработчика это вообще не проблема, как почему-то многие пытаются представить.

                                                                              Кстати, да, согласен. И даже без роста доходов с радостью бы перешёл. Перейти с ZF или Symfony2 на RoR или Django не сильно сложнее чем на Yii или CakePHP. MVC он в Африке MVC, а писать всё же приятней. Про тех, кто писал только под WordPress или Joomla -отдельный разговор, их средними php-разработчиками язык не поворачивается называть.
                                                                        • 0
                                                                          «Реалтайм» (без хайлоада) тоже на чём угодно можно писать (серверную часть), тормозить будут, имхо, прежде всего СУБД/ФС. Другое дело, что межзапросное кэширование на PHP стандартными средствами не очень тривиально. То же чтение настроек приложения из конфига на каждый запрос и вообще его явная инициализация явно избыточны, но, увы, многие приложения не рассчитаны на работу в условиях когда после завершения работы не происходит полная реинициализация глобального контекста. Но, имхо, это проблема больше разработчиков, а не языка. На любом языке я тоже напишу приложение, которое работает только в CGI режиме.
                                                                          • 0
                                                                            смотря что за субд. если речь о рсубд — тут да. если же мы говорим о mongo или хранилищах вроде redis/tarantool — то это весьма сложно.

                                                                            >То же чтение настроек приложения из конфига на каждый запрос и вообще его явная инициализация явно избыточны

                                                                            для этого надо настройки хранить в mongo, сам конфиг кешировать в рамках процесса.

                                                                            >Но, имхо, это проблема больше разработчиков, а не языка. На любом языке я тоже напишу приложение, которое работает только в CGI режиме.

                                                                            а на любом языке вы сделаете «горячую» замену кода в работающем приложении?

                                                                            на python я такую штуку сделал.
                                                                            • 0
                                                                              Я и на монго напишу тормозяще :) Ну нет, вроде быстродействующих средств осуществлять композицию. Агрегацию есть, а композицию нет. Как не крути, но получить сравнимое время выборки, скажем, по комментам на хабре и по топику, и по автору получится только если оба будут тормозить. Или дублировать информацию для разных срезов.

                                                                              Над остальными задачами не думал.
                                                                              • 0
                                                                                На php горячую замену кода делали люди года 3-4 назад. В чем собственно вопрос?

                                                                                Но она нужна лишь для тех «костыльных» приложений на других языках, которые не работают в изначальной идеологии php — запустился, быстро отработал, умер.
                                                                                • 0
                                                                                  >запустился, быстро отработал, умер.

                                                                                  прощай highload.
                                                                                  • 0
                                                                                    Разве? Вы много хайлоадов написали? :)
                                                  • 0
                                                    Очевидно, все твои проекты «СЕРЬЕЗНЕЕ» этих: facebook, контакт, youtube, wikipedia,…?
                                                    • 0
                                                      Очевидно, все Твои новые проекты «серьезнее» этих: fracebook, youtube, wikipedia, контакт?
                                                    • +24
                                                      > Я имею в виду весь этот рынок CMS, на котором к PHP конкуренты просто не подберутся и на пушечный выстрел (Wordpress, Joomla!, Drupal, vBulletin, MODx, TYPO и т. д.).

                                                      И слава богам. Последнее, что я хотел бы увидеть в своей жизни это массово-разрабатываемые cms-ки на rails.
                                                      • –2
                                                        Согласен с вами :) Хорошо, что комьюнити рельс пока не страдает от перенасыщения «хреновых» разработчиков.
                                                        • +5
                                                          Вы правы, но все же, какие на python/ruby есть хорошие аналоги Wordpress/Magento/MODx/etc., хотя бы по одной на область применения? Иначе получается не язык, а игрушка для высоких нагрузок (пишем с нуля) или просто поиграться (пишем с нуля). Я хотя и пхп-ник, но пишу на Синатре (очень уж мне нравится) и изредка на RoR. Но без нормальной работы, например, в финансовой сфере, продажи, магазины, язык так и остается «для избранных».
                                                          • –1
                                                            spreecommerce.com/
                                                            В нее недавно влили достаточно денег, чтобы она стала очень крутой :) Я уже молчу о том, что система расширений рвет в жопу магенту.
                                                            • 0
                                                              Я смутно понимаю необходимость CMS на рельсах. Для более-менее нестандартного сайта все равно придется кастомизировать CMS, добавлять какие-то свои модули и т.д. За аналогичное время безо всяких CMS собирается кастомный сайт со сторонними гемами. Нужен и-нет магаз – бери spree, нужны блоги/новости – есть много готовых решений, хотя и свое пишется за 5 минут. Нужна админка – activeadmin, нужно что-то еще – поищи нужный гем, с вероятностью 99% что-то готовое уже есть.

                                                              + совсем не понял про «для избранных»: куча вакансий, куча проектов. Конечно, меньше, чем на php, но достаточно :)
                                                              • 0
                                                                Ниша one-click-cms'очек давно забита php и это нормально, другой вопрос, что при реквест кастомной фичи от заказчика начинается ад в глаза php программистов. Я собственно говоря имел опыт, когда рельсовиков пригласили взамен php, потому что поддерживать drupal ни у кого уже не было сил :)
                                                                • 0
                                                                  Многие нестандартные сайты начинаются со стандартных, в которых сразу нужны магазин, блог, новости и админка (в терминах предметной области, а не структуры БД). Плюс возможность устанавливать сторонние модули из этой админки «в один клик», без программирования и консоли. То есть CMS это продукт для веб-мастера, а то и вообще менеджера, а не программиста. Самое главное в нём, пожалуй, как раз админка.
                                                                  • 0
                                                                    Хм, ну поставить CMS и начать работать сразу, не будучи программистом – ладно, довод в пользу CMS. Только вот решение это не оч дальновидное с точки зрения бизнеса: бизнес так или иначе вырастет, потребуется что-то нестандартное и придется звать программиста, который будет все это дело кастомизировать. Но кастомизировать он будет уже что-то готовое. И не факт, что выбранное правильно (может менеджер плохую CMS выбрал, он ведь может такое :)

                                                                    И вот тут возникает проблема: кастомизировать уже готовое или написать заново. Владелец бизнеса очень неохотно (судя по моему опыту) пойдет на переписывание, т.к. с его точки зрения кастомизировать проще. Но адекватный человек за такую неблагодарную работу захочет довольно много денег, чтобы компенсировать свои предстоящие душевные травмы. Владелец бизнеса столько платить, возможно, не захочет и наймет кого-то другого с более низкой квалификацией за 100р. Замкнутый круг.

                                                                    Мораль такова: каждый должен делать свое дело. Программист – разрабатывает, веб-мастер поддерживает, менеджет штаны просиживает.
                                                                    • +2
                                                                      Для бизнеса зачастую определяющим является минимизация стартовых затрат денег и времени. Грубо говоря, побыстрее и подешевле запустить. И однозначно сказать, что это недальновидно сложно. Потратить час/день/неделю/месяц работы веб-мастера или день/неделю/месяц/год работы программиста ради сайта, на который неизвестно зайдёт ли вообще кто-то нибудь кроме директора? Очень многие постараются минимизировать риски потери денег. И «скупой платит дважды» тут не совсем корректно употреблять.

                                                                      А вот если сайт, запущенный за час, уже начал приносить деньги, то тут уже другие критерии должны работать, да и заплатить хорошо хоть за квалифицированную переделку с ноля, хоть за квалифицированную кастомизацию можно себе позволить, не трогая другие статьи доходов, не изымая денег из оборотных капиталов, а на «самообеспечении».

                                                            • +10
                                                              "… потому что хотя он и не безупречен, он работает…" — самые главные слова. Соглашусь со всем. Статья «PHP: a fractal of bad design» настолько массивна, что у читателя не возникает сомнений, что что-то там может быть неправдой. Спасибо за перевод :)
                                                              • 0
                                                                Абсолютно же не важно на чем работать, да? ;)
                                                                • +1
                                                                  по мне так, главное чтобы самому тебе нравилось и было удобно! :)
                                                              • +6
                                                                Не буду особо цепляться, НО:
                                                                HTTP – это объект первого класса. Никакие другие популярные языки этого не предоставляют. Ни Python, ни Ruby, ни C, ни JavaScript. PHP и HTTP – одного поля ягоды. Вы можете поспорить, что это не так оптимально, но это первый класс. Вам не надо никаких библиотек или фреймворков, чтобы говорить на HTTP.
                                                                HTTP — не объект, а протокол )))

                                                                PHP и HTTP разного поля ягоды, ибо одно — язык программирования, а другое протокол передачи гипертекста

                                                                Вам обязательно надо библиотеки и/или фреймворки, потому что иначе вы напишете ужаснейший велосипед на PHP в котором будет куча дыр. Да и если вы будете писать на голом PHP работу вы вряд ли найдёте приемлимую.
                                                                • +3
                                                                  > Да и если вы будете писать на голом PHP работу вы вряд ли найдёте приемлимую.

                                                                  А вот в этом я не уверен. PHP позволяет с минимальными усилиями писать программный код любому индивиду, способному хоть как-то последовательно формулировать выполнение задач (порядок действий). На рынке труда программистов не хватает, очень не хватает. Поэтому на работу обладая даже минимальными навыками в PHP устроится легко. Зарплата, конечно, будет низкой, но зато это работа в офисе, и есть прямой путь профессионального роста.
                                                                  • –10
                                                                    >PHP позволяет с минимальными усилиями писать программный код любому индивидуинвалиду, способному хоть как-то последовательно формулировать выполнение задач (порядок действий).

                                                                    Не удержался, простите:)
                                                                    • +3
                                                                      Вы наверно не летаете на самолетах с автопилотом потому что в это время можно посадить макаку за штурвал.
                                                                    • 0
                                                                      я с вами согласен, но как бы я не любил php думаю всю жизнь на такой работе не проживешь :(
                                                                      • +1
                                                                        Почему нет если не забывать о саморазвитии? Работа в проектах с многомиллионной, а то и почти миллиардной аудиторией не может быть достаточно интересной разве?
                                                                        • 0
                                                                          интересна, стремлюсь к этому как могу, даже фейсбук доказал что на пхп можно делать огромные приложения, просто не хочу знать только один язык, их ведь так много и каждый заточен под свои задачи, думаю будет правильно использовать все что есть а не зацикливатся. в общем это только мое мнение.
                                                                          • +1
                                                                            Facebook транслирует PHP-код в С++ код и выполняется нативно.
                                                                            См. HipHop
                                                                            • +1
                                                                              Ну и что? А С++ тоже компилится и выполняется нативно. Главное, какой язык читают люди.
                                                                              • 0
                                                                                для python есть транслятор cython.
                                                                                интеграция с сишными/плюсовыми библиотеками делается за несколько минут.

                                                                                не нравится встроенная реализация регекспов? ок, можно взять из libpcre/re2 или яндексовскую pire ( clubs.ya.ru/company/replies.xml?item_no=30753 )

                                                                                хотим actor model(в erlang-style) — берем gevent + zeromq.

                                                                                бесшовная интеграция с C++ (и наоборот).

                                                                                Основная идея оптимизации со скриптовыми языками — это профайлинг + переписывание горячих участков на C/C++.
                                                                                Легко ли это делать для php?
                                                                            • 0
                                                                              Зацикливаться зачастую заставляют внешние по отношению к собственно разработке условия, экономические например.
                                                                      • +1
                                                                        «Да и если вы будете писать на голом PHP работу вы вряд ли найдёте приемлимую.», но разве чистый PHP не является основой а «библиотеки и/или фреймворки» подбираются под конкретную задачу?
                                                                        • 0
                                                                          Я например некоторые библиотеки сам себе писал, так сказать под себя.
                                                                          • –2
                                                                            Например свое подобие ActiveRecord'а
                                                                            • +1
                                                                              Ну да, каждый PHP-программист должен написать СвоюСамуюЛучшуюВмире ЦМС )))
                                                                              • 0
                                                                                И что в этом плохого? Если бы это было не так, то тот же WordPress не появился бы, как и куча других популярных CMS. А так есть конкуренция, есть развитие.
                                                                                • +1
                                                                                  На самом деле написание собственной ORM отлично прокачивает скил проектирования, особенно если уйти в сторону от ActiveRecord и прочитать в процессе разработки соответствующую литературу (для начала, «шаблоны корпоративных приложений», потом может и на UML потянет и т.д.).

                                                                                  Безусловно, библиотеки нужны, но знать как они устроены и быть способным при необходимости написать что-то большее гораздо важнее для профессионального программиста. Кроме того, развитая способность к разработке чего то нестандартного позволит перейти на уровень выше и стать проектировщиком, с этого момента часть скучной и неинтересной работы по написанию очевидного кода (= рутины) можно переложить на тех кто в это время полностью освоил какой либо разработанный вами framework :)

                                                                                  Поэтому изучение одного framework-а, который все делает за вас, считаю тупиковым, т.к. он ведет к отмиранию способности проектировать что-то большее чем набор контроллером в моделей (если это вообще можно считать проектированием). И кстати, тут на хабре где-то год назад наверное проскакивал топик/вопрос от человека который пошел по пути потребления и в итоге обнаружил, что стал не способен создать ничего нового. Найти не смог, к сожалению.

                                                                                  Поэтому велосипедить надо, но в меру.
                                                                                  • 0
                                                                                    Упс, промахнулся, это ответ на ироничный комментарий solver-а
                                                                                    • 0
                                                                                      Создание сайтов давным-давно стало рутиной. Зачем искать что-то там, где уже ничего нет?

                                                                                      Если создание сайтов — рутина, бессмысленная и беспощадная, изучение одного-двух хороших фреймворков позволяет справляться с этой рутиной быстрее и безболезненней, оставляя время на личную жизнь и развитие в более перспективных профессиональных областях…
                                                                                      • +1
                                                                                        > Создание сайтов давным-давно стало рутиной.
                                                                                        К счастью интересные задачи все еще встречаются.

                                                                                        > более перспективных профессиональных областях…
                                                                                        Проектирование, по вашему, недостаточно перспективно?
                                                                                        • 0
                                                                                          Ну так само собой, php-программистов — миллионы, никто их не пускает в серьезные интересные проекты. Интересный проект гораздо проще получить если ты рельсовик или питонист :)
                                                                                          • 0
                                                                                            Уж слишком вы категоричны.
                                                                                            Не соглашусь с вами.

                                                                                            Знаю системы на РНР, которые работают на целую республику.
                                                                                            Питонистов и рубистов туда никто не пускает.

                                                                                            Да и, уж простите, но Фейсбук также с вами не согласен.
                                                                                            • 0
                                                                                              Вы меня не так поняли, потому что я не очень хорошо выразился. Суть в том, что найти хорошую работу среднестатистическому php программисту труднее, чем рельсовику :) Мне, по крайней мере, так кажется.

                                                                                              А на счет вашего тонкого замечания в сторону рельс — я вот сейчас работаю над проектом где мы используем Rails + EventMachine (руби аналог node.js) + websocket и прочие comet реализации.
                                                                                              • 0
                                                                                                А начинающему проще. Мне, по крайней мере, так кажется. :)

                                                                                                А для websocket использую phpdaemon сейчас. Когда возниткнут проблемы с масштабированием буду их решать, по мере поступления.
                                                                                            • +1
                                                                                              p.s. И что для вас «интересный» проект? Сборка готовых гемов?
                                                                                        • +1
                                                                                          WP отличная штука, слава богу, что наблюдается последнее время тренд ухода с него на более легкие и человечные решения, по крайней мере в прослойке программистов :)
                                                                                          • 0
                                                                                            WP отличная штука

                                                                                            С точки зрения пользователя — бесспорно, а с точки зрения разработчика и интегратора… ну, it depends. Уж сколько говнокодерских плагинов и шаблонов (среди коммерческих в том числе) к нему, просто не пересчитать. Никогда не угадаешь, где тебя бомба замедленного действия поджидает, через которую могут весь сайт положить.
                                                                                        • 0
                                                                                          Мало того я ее написал и скоро представлю на обозрение, не сказал бы что она лучшая, но во всяком случае для меня она в разы проще как в написании модулей так и в обработке контента, а оно и естественно потому что сделана на собственном мини MVC фреймворке, при этом функционал не меньше чем у вордпресс + есть модуль магазина =).
                                                                                        • 0
                                                                                          Наверное очень красиво получилось =P
                                                                                          • –5
                                                                                            )))) Ну актив рекорд типа того

                                                                                            $order_cart = Db_Lib::Init()
                                                                                            -> select(«shop_orders_products», "*")
                                                                                            -> where(array(«id_order» => $_GET['id']))
                                                                                            -> query()
                                                                                            -> fetch_rows();
                                                                                            • +4
                                                                                              Ну наверное это красиво, я на php не работаю слава богу, в рельсе было бы как-то так:

                                                                                              ShopOrderProducts.find(params[:id])


                                                                                              но вы продолжайте ;)
                                                                                              • +1
                                                                                                И зачем вы так? =) Пошел учить рельсу )))))
                                                                                                • +1
                                                                                                  Учите Ruby, рельса это второе :)
                                                                                                  • +1
                                                                                                    Я прост думал Ryby on Rails это и есть язык, сори за нубство
                                                                                                    • +4
                                                                                                      :D типичный php программист
                                                                                                • +4
                                                                                                  ShopOrderProducts.find(params[:id])


                                                                                                  Ну на пхп тоже можно так написать:
                                                                                                  ShopOrderProducts::find($params->id)
                                                                                                  


                                                                                                  Покажите, что стоит за вашим find.
                                                                                                  • 0
                                                                                                    На пхп? Вызвать метод класса? Или может это какая-то библиотека? ;)

                                                                                                    Я так понимаю вам интересен оверхед от всех этих красивых абстракций? Ну так вот — он небольшой ;) Проекты с нагрузкой нормально работают.
                                                                                                    • +1
                                                                                                      Ну да. Что на пхп, что на руби можно написать библиотеку, которая предоставит такой синтаксис.
                                                                                                      Вопрос в том, что надо сделать, чтобы можно было писать это.

                                                                                                      Я не про производительность. Уверен, запрос к базе, что в пхп, что в руби выполнится с одной скоростью.
                                                                                                      • 0
                                                                                                        Ну если хотите использовать ActiveRecord без рельс, то можно сделать что-то подобное — snippets.aktagon.com/snippets/257-How-to-use-ActiveRecord-without-Rails, при этом надо понимать, вы из коробки будете иметь разные енвайроменты, миграции и тп.
                                                                                                        • +4
                                                                                                          Ну и в ПХП можно использовать какую-либо библиотеку (например, Doctrine), которая предоставляет интерфейс. Сам не использовал, т.к. сидел на Kohana, а потом ушёл из серверного программирования
                                                                                                          • –2
                                                                                                            Я кстате и не спорю, что в php тоже есть хорошие решения, беда в том, что вы первый человек в этом треде, который говорит об этом ;)
                                                                                                            • –1
                                                                                                              А зачем играть в а у меня есть то-то а у меня есть то-то, это не конструктивно.
                                                                                                              • +1
                                                                                                                Почему?
                                                                                                                • 0
                                                                                                                  потому что всем известно, что языки мощные и есть сопутствующий инструментарий. Это как сравнивать Ламборгини и Феррари вроде один уровень, а разница в мелочах.
                                                                                                              • 0
                                                                                                                Я кстате и не спорю, что в php тоже есть хорошие решения, беда в том, что вы первый человек в этом треде, который говорит об этом ;)

                                                                                                                Ну в кое-каком роде согласен, что пхп — это фильтр, на котором отсеялось и осталось огромное количество горе-разработчиков.
                                                                                                                Но надо быть и объективным тоже ;)
                                                                                                              • 0
                                                                                                                Зачем говорить об очевидных вещах?

                                                                                                                Но если хочется… Кстати, а в руби запилили поддержку DataMappper, UnitOfWOrk и т. п.? Или всё так же любой проект на рельсах с БД нарушает принцип единственной ответственности? :)
                                                                                                                • 0
                                                                                                                  У рельс один простой паттерн — ActiveRecord, сами понимаете, он отличается от UnitOfWork.
                                                                                                                  dm -> datamapper.org/ (http://rubydoc.info/gems/datamapper2/0.0.1/DataMapper/UnitOfWork)
                                                                                                                  • +1
                                                                                                                    TableDataGateway ещё проще :)

                                                                                                                    А этот DataMapper как-то производит впечатление, что в нём от паттерна только название.
                                                                                                                    # create makes the resource immediately
                                                                                                                    @post = Post.create(
                                                                                                                      :title      => "My first DataMapper post",
                                                                                                                      :body       => "A lot of text ...",
                                                                                                                      :created_at => Time.now
                                                                                                                    )
                                                                                                                    
                                                                                                                    # Or new gives you it back unsaved, for more operations
                                                                                                                    @post = Post.new(:title => ..., ...)
                                                                                                                    @post.save                           # persist the resource
                                                                                                                    


                                                                                                                    Как-то это у меня с ActiveRecord больше ассоциируется.
                                                                                                                    • 0
                                                                                                                      Это вполне возможно, вообще очень редко слышо о UnitOfWork в руби мире, не особо оно популярно.
                                                                                                      • 0
                                                                                                        Подозреваю, что без кодогенератора не получится. В руби, если не изменяет память, как и в JS, класс — это тоже объект, и в него можно сколько угодно добавлять методы. А вот в PHP такое не прокатит.
                                                                                                        • 0
                                                                                                          Подобное можно сделать через магические методы и callback-и
                                                                                                        • 0
                                                                                                          class ShopOrderProductsTable extends AbstractTable {
                                                                                                            protected $tableName = 'shop_orders_products';
                                                                                                          
                                                                                                            public function findByOrderId ($id) {
                                                                                                              return $this->find(['order_id' => $id]);
                                                                                                          }
                                                                                                          


                                                                                                          Как-то так можно обходиться без кодогенерации. Зачем добавлять методы динамически, если структура БД известна на этапе «компиляции»?
                                                                                                          • 0
                                                                                                            Я так понимаю, тут спорят об active record. А там не принято создавать отдельный класс на entity и отдельный — на таблицу. Там сам entity содержит статические методы для поиска по множеству объектов данного типа. Вот я про такое и писал. Вот только действительно, в 5.3 появился __callStatic, который и такое может. Однако, мне не совсем понятно, как оно будет работать с наследованием, да и сама необходимость наследования несколько смущает.