Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 68
Меня всегда интересовало, зачем пытаться сделать в PHP то, чего он не умеет, а потом кричать о его кривой реализации OOP?
Как-то обхожусь стандартным функционалом и не пытаюсь запихать в скрипты реализацию всех паттернов подряд. Выйдут примеси в том или ином виде скоро, вот и будем радоваться. Темболее что вроде будут Graits и они compile-time.
Как-то обхожусь стандартным функционалом и не пытаюсь запихать в скрипты реализацию всех паттернов подряд. Выйдут примеси в том или ином виде скоро, вот и будем радоваться. Темболее что вроде будут Graits и они compile-time.
Обратите внимание на мою просьбу. Факты, пожалуйста. Вы считаете, что PHP не умеет делать примеси? Мы с Леонидом доказали, что умеет и очень даже неплохо. Определите, что означает «умеет/не умеет»? Этой возможности нет в языке? Ни один паттерн ООП проектирования не входит в PHP на «родном» уровне, но это не значит, что я не могу реализовать в PHP синглтон, компилятор или фасад.
Я не вижу никакой причины ждать трейтов или графтов сложа руки, тем более, что обе эти реализации от примесей отличаются. И уж тем более отличаются от моей реализации, которая позволяет динамически подмешивать примеси, не загружая ни класс-агрегатор, ни примесь.
Я рад, что вы обходитесь стандартным функционалом. Но не всех он устраивает, даже если отбросить тот факт, что примеси мы реализовывали в качестве упражнения.
Я не вижу никакой причины ждать трейтов или графтов сложа руки, тем более, что обе эти реализации от примесей отличаются. И уж тем более отличаются от моей реализации, которая позволяет динамически подмешивать примеси, не загружая ни класс-агрегатор, ни примесь.
Я рад, что вы обходитесь стандартным функционалом. Но не всех он устраивает, даже если отбросить тот факт, что примеси мы реализовывали в качестве упражнения.
А нам потом работать с фреймворками, в которых напихано огромное кол-во классов, глубокое наследование, классы реализуют по 3-4 паттерна каждый и всё это ЗВЕРСКИ тормозит.
PHP не создан для такого. Такие вещи нужно делать очень аккуратно, особенно те что runtime. Даже разработчики очень осторожно вносят runtime фитчи, делая всё что могут в compile time. Не зря ведь…
PHP не создан для такого. Такие вещи нужно делать очень аккуратно, особенно те что runtime. Даже разработчики очень осторожно вносят runtime фитчи, делая всё что могут в compile time. Не зря ведь…
Разве вы решаете, для чего создан PHP? Вы видели размер моей реализации примесей (особенно, если, скажем, выкинуть реестр) или реализации Леонида? У него вообще там 80 строк всего. Что, сложно разобраться? Где там глубокое наследование и 3-4 паттерна? Мы даже тесты быстродействия привели, чтобы вы не дай бог не подумали, что все и правда ЗВЕРСКИ тормозит. Давайте не будем разводить демагогию.
Примеси прекрасно существуют во многих ЯП, легко документируются. Да, конечно, когда вам надо забить гвоздь в стену, можно особо не заморачиваться с инструментами и просто бабахнуть его в стену. А если вам нужно построить дом? Будем утверждать, что всякая инженерная работа, архитектурные паттерны, проектирование, тестирование, расчеты, графики — это все ЗВЕРСКИ тормозит наш проект? Ну, давайте попробуем построить дом только молотком и гвоздями. Кто только в нем жить потом рискнет?
Примеси прекрасно существуют во многих ЯП, легко документируются. Да, конечно, когда вам надо забить гвоздь в стену, можно особо не заморачиваться с инструментами и просто бабахнуть его в стену. А если вам нужно построить дом? Будем утверждать, что всякая инженерная работа, архитектурные паттерны, проектирование, тестирование, расчеты, графики — это все ЗВЕРСКИ тормозит наш проект? Ну, давайте попробуем построить дом только молотком и гвоздями. Кто только в нем жить потом рискнет?
Проблема в том, что PHP не создавался на подобие других ЯП, у него есть чёткая ниша и в нём довольно много своих особеннойстей и не все фитчи, существующие в других ЯП, списываются в KISS концепцию самого языка. Нет, это не значит что не нужно вообще ничего делать, просто посмотрите историю языка. В большинстве случаев фитчи языка имеют свою особенность, отличающую его от других языков.
Я уже не говорю о специфике WEB, важности минимальной латентности и.т.д.
Я уже не говорю о специфике WEB, важности минимальной латентности и.т.д.
> Проблема в том, что PHP не создавался на подобие других ЯП, у него есть чёткая ниша
Именно. Эта ниша — hypertext processing, о чем намекает название. В этом направлении инструмент неплох, имеет множество функций, но и не лишен недостатков. Вот только большинство его использующих этого не понимают и пихают туда что попало, пытаясь с помощью одних лишь молотка и топора построить целый небоскрёб. В итоге получается предсказуемое говно, которое монструозно, шатается и разваливается, требует тонны костылей и подпорок, тормозит существенно.
Правильно было сказано очень давно: для каждой задачи свой инструмент.
Именно. Эта ниша — hypertext processing, о чем намекает название. В этом направлении инструмент неплох, имеет множество функций, но и не лишен недостатков. Вот только большинство его использующих этого не понимают и пихают туда что попало, пытаясь с помощью одних лишь молотка и топора построить целый небоскрёб. В итоге получается предсказуемое говно, которое монструозно, шатается и разваливается, требует тонны костылей и подпорок, тормозит существенно.
Правильно было сказано очень давно: для каждой задачи свой инструмент.
Есть некоторые интересные паттерны, которые реализуются с помощью примесей. Поскольку примесей в РНР нет, это хорошо, что автор описал как их эмулировать. Кому-то пригодится.
В РНР4 была неполноценная поддержка ООП, Вы тогда тоже неадекватно реагировали на ОО код и продолжали программировать в процедурном стиле?
В РНР4 была неполноценная поддержка ООП, Вы тогда тоже неадекватно реагировали на ОО код и продолжали программировать в процедурном стиле?
Ну ООП в 4-й версии был. Не такой как в PHP5, но худо бедно был. Да и я тольком то 4-ю версию не застал, всё больше на 5-й работал :)
Это кому-то пригодится почти всегда превращается в «Надо и мне такую хрень добавить — это же круто!». Без большого стикера «Использовать осторожно иначе разачаруетесь в смысле жизни!» постить нельзя, потому что большая часть PHP'ников это бездумные кодеры. А нам потом это расхлёбывать.
Это кому-то пригодится почти всегда превращается в «Надо и мне такую хрень добавить — это же круто!». Без большого стикера «Использовать осторожно иначе разачаруетесь в смысле жизни!» постить нельзя, потому что большая часть PHP'ников это бездумные кодеры. А нам потом это расхлёбывать.
Это кому-то пригодится почти всегда превращается в «Надо и мне такую хрень добавить — это же круто!».
И какой из этого следует вывод? :) Что в интернете ничего выкладывать нельзя? Вдруг кто-то добавит это в виде «хрени» к своему проекту?
Концепты демонстрируются не для того, чтобы это «кому-то пригодилось», а для демонстрации и получения критики на решение. Если кто-то внедряет ваш концепт туда, где это абсолютно лишнее, вы в этом не виноваты. И ворчать «развели тут ламеров своими концептами, а нам потом расхлебывать» с моей точки зрения глупо.
Стикеры «Использовать осторожно иначе разачаруетесь в смысле жизни!» на каждую вторую свою статью я лично вешать не собираюсь. И не хочу, чтобы это делал кто-то другой, потому что это демонстрирует сомнение в интеллектуальных способностях читателей. Разумеется, в отношении кого-то это сомнение может оказаться оправданным, но лепить стикеры? Нет.
Как показывает практика, всегда находятся дибилы :) А потом эти дибилы постят слёзные посты на хабр, засоряя его :)
А ещё вспомните выражение «Мы отвественны за тех, кого приручили». Вот вы их щас научили, а они налепят говнокода :) И вы их не предупредили, что это потенциально неъорошая штука в кривых руках.
А ещё вспомните выражение «Мы отвественны за тех, кого приручили». Вот вы их щас научили, а они налепят говнокода :) И вы их не предупредили, что это потенциально неъорошая штука в кривых руках.
Я согласен, дебилов полно :) Но они — неотъемлемая часть жизни. Продолжая эту странную линию дискуссии, я могу сказать, что лучше этим людям дать в руки виртуальную нехорошую штуку. А то, вдруг им станет скучно, и они возьмут в руки вполне себе физическую да еще на улицу с ней...? :) :)
А если серьезно, то, может я и не прав, но в своих статьях я не буду подозревать читателей в недостатке профессионализма. Если человек не понимает, где можно что-то лепить, а что нельзя, ярлык не поможет. Просто потому, что он всегда сам знает, как и что можно и нужно. А если понимает — ему ярлык и не нужен.
А если серьезно, то, может я и не прав, но в своих статьях я не буду подозревать читателей в недостатке профессионализма. Если человек не понимает, где можно что-то лепить, а что нельзя, ярлык не поможет. Просто потому, что он всегда сам знает, как и что можно и нужно. А если понимает — ему ярлык и не нужен.
Да вам какая разница? Ну налепят говнокода, ну угробят пару проектов. И что? Чем менее конкурентноспособны программеры на рынке, тем выше ваша ценность как специалиста. Вы должны конкурировать не с дибилами, а с нормальными оппонентами :)
Просто потом нас вызывают что бы разобраться в этом говнокоде и сильно удивляются что ценник на его разбор в 2-3 раза выше чем просто выполнить работу :)
Цените это! Деньги вам сами в руки просятся!
После пары таких работ не хочется даже за большие деньги этим заниматься. Не каждый имеет упёртость барана, что бы в этом копаться.
Вмешаюсь в эту милую дискуссию.
Вы оба так говорите, будто в жизни своей говнокода не писали, а вот так вот сразу родились гениальными программистами. Быдлокодеры есть везде, не только в PHP и в процентном соотношении приблизительно столько же. Ну так, в среднем по больнице. Просто из-за того, что порог вхождения именно в этой нише очень низок — есть постоянный приток «свежей крови» (это к тому, что армия «пэхэпэ-праграмистов» и так уже сравнима с армией небольшого европейского государства) и, соответственно, растёт количество говнокода.
Мне и самому не нравится порой разбирать чужой бардак и приводить всё в порядок, тратя тысячи нервных клеток и уничтожая литры кофе. Но с другой стороны: если не нравится — отказывайтесь от такой работы, делайте что-то новое, что-то лучшее.
Я полностью согласен с тезисом увеличения «ценности как специалиста», просто уже достало смотреть на то, как новичков с порога говном обливают.
Вы оба так говорите, будто в жизни своей говнокода не писали, а вот так вот сразу родились гениальными программистами. Быдлокодеры есть везде, не только в PHP и в процентном соотношении приблизительно столько же. Ну так, в среднем по больнице. Просто из-за того, что порог вхождения именно в этой нише очень низок — есть постоянный приток «свежей крови» (это к тому, что армия «пэхэпэ-праграмистов» и так уже сравнима с армией небольшого европейского государства) и, соответственно, растёт количество говнокода.
Мне и самому не нравится порой разбирать чужой бардак и приводить всё в порядок, тратя тысячи нервных клеток и уничтожая литры кофе. Но с другой стороны: если не нравится — отказывайтесь от такой работы, делайте что-то новое, что-то лучшее.
Я полностью согласен с тезисом увеличения «ценности как специалиста», просто уже достало смотреть на то, как новичков с порога говном обливают.
Новички бывают такие, что дадут фору некоторым с опытом в 2-3 года. Зависит от людей. К сожалению слишком многие не понимают, что не их это.
Никто не поливает новичков. Просто есть две крайности: в одном случае с ними возятся как с детьми малыми, а в другом кидают в воду как собачат, если выплывет — будет толк.
Научить думать своей головой очень тяжело. Научить анализировать и критически относиться к всему, еще труднее. Но если человек поймет, что от него хотят, толк не просто будет, он будет звездой.
Научить думать своей головой очень тяжело. Научить анализировать и критически относиться к всему, еще труднее. Но если человек поймет, что от него хотят, толк не просто будет, он будет звездой.
Знаете, когда вы уже 6-7 лет в индустрии и вас приглашают на собеседования с зарплатами по 2.5-3к$ и мелочёвкой вы просто не занимаетесь, потому что это скушная рутина, ни за какие коврижки вас не заставишь разбираться в каком-то говнокоде — ну разве что где-нить на Гавайских островах с ноутом на месяца 2 all inclusive :)
Зачем коментить то что вам не нужно и лишнее или не понимаете(лишь бы что нибудь прокоментить ). Авторам(примисей) спасибо,
Вообще я не говорю что сам подход плохой или автор какой-то не такой.
Я о том, что делая такие посты и не делая акцента на том, что использование таких вещей должно хорошо продумываться, приводит больше к негативным последствиям, чем к хорошим.
Я о том, что делая такие посты и не делая акцента на том, что использование таких вещей должно хорошо продумываться, приводит больше к негативным последствиям, чем к хорошим.
Мне кажется, все негативные последствия и тонкие моменты я описал в статье. Впрочем, может быть, вы и правы. Просто усердствовать с ярлыками не стоит, а так — они нужны и полезны.
Всегда нужно подходить критически к информации. Если вы слепо верите гуру, то грош вам цена как программисту.
Если бы я слепо верил, моих коментариев тут небыло бы :)
А зачем тогда другим разжевывать, что написанное в статье не совсем хорошо или хорошо только с такими ограничениями? Пусть своей головой думают
Если так подходить, то у нас будут одни говнокодеры и единицы программистов — мир станет хуже, интернет превратиться в помойку, и.т.д. :)
Зачем вообще школы нужны? Может, ну его? Зачем деньги тратить на образование в ВУЗах? Пусть своим умом лучше… А?
Для общего образования. В школах учат запоминать информацию, пересказывать информацию, записывать информацию, делать операции сложения, умножения и прочее. Анализировать и применять накопленные знания особо не учат.
Да? А вообще-то должны :) Ну а в ВУЗах?
Должны, но не учат. В ВУЗах аналогичная ситуация.
Ну вот видите. Раз аналогичная ситуация, и должны, но не учат, значит, людей нужно учить применять накопленные знания. Если вы, скажем, слишком эгоистичны для этого — это другой вопрос. А мне нравится делиться знаниями и я буду продолжать это делать.
Я как раз делюсь знаниями. Просто я не разжевываю в мелкую кашу все, оставляя пищу для ума.
Я думаю, «мелкая каша» субьективное понятие и точное его значение зависит величины эго и уровня знаний. Вы не согласны?
Мелкая каша, это когда не остается пищи для ума.
А «когда не остается пищи для ума» — это когда?
Это когда информация подается с описанием всех условий, при которых она является истинной.
А почему нельзя подавать информацию с описанием всех условий, для которых она является истинной?
Потому что не остается пищи для ума.
Почему не остается? Разве пища для ума — это исключительно только все условия при которых данная информация истинна? А как же остальное?
Что остальное?
Ну, например, я говорю «Примеси можно использовать для расширения функционала приложения. Это истинно всегда». Я описал все условия, при которых данная информация истинна? Вроде да. Но пищи для ума тут полно еще :) Когда их использовать плохо, когда хорошо, что будет, если их использовать, как изменится система и т.д.
А я говорю, что примеси в PHP запрещены для расширения функционала приложения. Это тоже истинно.
Юниоры воспринимают информацию под другим углом. Они не будут задумываться, хорошо ли использовать примеси или нет. Каждый прочитает то, что он хочет прочитать, и там нет места размышлениям. Один увидит в вашем выражении, что примеси нужно использовать всегда. Второй увидит, что примеси можно использовать только для расширения функционала и так далее. Задумываться начнет только тогда, когда будет задан вопрос не в лоб, а с подковыркой. Например, чем отличается ООП реализация в PHP от JS?
Юниоры воспринимают информацию под другим углом. Они не будут задумываться, хорошо ли использовать примеси или нет. Каждый прочитает то, что он хочет прочитать, и там нет места размышлениям. Один увидит в вашем выражении, что примеси нужно использовать всегда. Второй увидит, что примеси можно использовать только для расширения функционала и так далее. Задумываться начнет только тогда, когда будет задан вопрос не в лоб, а с подковыркой. Например, чем отличается ООП реализация в PHP от JS?
Возможность не наследовать от агрегатора — на мой взгляд, фича крайне важная. Я буквально пару месяцев назад искал реализацию mixin на пхп и нашел только вариант Леонида и вынужден был от него отказаться, т.к. пришлось бы переделывать логику работы ORM (родительские классы для моделей, которые надо было расширить, генерились автоматически), если бы вовремя нашел ваш вариант, мое решение было бы менее кривым :)
В 5.3 можно активировать специальный сборщик мусора для этой цели
Он включен по умолчанию ( us2.php.net/manual/en/info.configuration.php ). Так что его можно выключить.
, но он замедляет работу скрипта в целом, так что это нежелательно.
Замедляет каждый раз, когда количество отслеживаемых существующих объектов превышает 10 000 (можно переопределить при сборке, нельзя настроить через php.ini). Если после очистки буфер потенциальных целей переполнен, отслеживание новых объектов не производится.
Трекинг потенциальных целей выполняется независимо от состояния опции zend.enable_gc, замедление происходит только при вызове сборщика циклических ссылок. Заставить занимать значительную долю во времени выполнения скрипта можно, но довольно сложно. В целом замедление обычно не превышает 5-7%, при этом экономит солидные объемы памяти (что позволяет обслуживать большее количество клиентов параллельно).
блин, раньше времени отправилось.
Не поможет. Объект удаляется при достижении 0 счетчиком ссылок на него. Деструктор вызывается перед удалением объекта. Счетчик ссылок в случае циклического графа без дополнительных телодвижений не достигает 0 никогда. Таким образом, деструктор не будет вызван автоматически до окончания работы скрипта (если zend.enable_gc=false или версия PHP младше 5.3).
Можно вызвать деструктор (а лучше — его аналог, дабы избежать двойного вызова деструктора на одном и том же объекте) вручную перед выходом из области видимости объекта — но это означает, по сути, попытку ручного менеджмента памяти. Вы не должны этого хотеть в PHP.
Как исправить эту ошибку? В обеих реализациях сделать это довольно просто, воспользовавшись не слишком часто используемой возможностью PHP – деструктором. Нужно добавить деструктор, принудительно обнуляющий ссылку на владеющий класс, в примесь и деструктор в класс-агрегатор, очищающий список примесей данного класса.
Не поможет. Объект удаляется при достижении 0 счетчиком ссылок на него. Деструктор вызывается перед удалением объекта. Счетчик ссылок в случае циклического графа без дополнительных телодвижений не достигает 0 никогда. Таким образом, деструктор не будет вызван автоматически до окончания работы скрипта (если zend.enable_gc=false или версия PHP младше 5.3).
Можно вызвать деструктор (а лучше — его аналог, дабы избежать двойного вызова деструктора на одном и том же объекте) вручную перед выходом из области видимости объекта — но это означает, по сути, попытку ручного менеджмента памяти. Вы не должны этого хотеть в PHP.
Вы никогда не пробовали с помощью PHPExcel генерировать несколько больших xls файлов подряд? Там возникает вот такая вот утечка памяти, связанная с циклическими ссылками. Посмотрите там как работает $objPHPExcel->disconnectWorksheets() Попробуйте следующий кусочек кода:
Деструктор вызывается не сборщиком мусора, а тогда, когда я принудительно обнуляю ссылку. И счетчик ссылок для объекта уменьшается соответственно.
Конечно, программист не должен хотеть вручную заниматься управлением памятью, если язык реализует сборщик мусора, но если другого выхода нет, это просто придется сделать. Так, например, в случае с PHPExcel это просто необходимо при его использовании в версиях до 5.3. Он просто ОЧЕНЬ прожорливый до памяти. На один прайс-лист может до 100Мб отъедать. Не всегда это приемлемо.
<?php
class A{
public function __destruct() {
echo "Destructor called!\r\n";
}
}
$a = new A();
$a = null;
echo("End of program\r\n");
Деструктор вызывается не сборщиком мусора, а тогда, когда я принудительно обнуляю ссылку. И счетчик ссылок для объекта уменьшается соответственно.
Конечно, программист не должен хотеть вручную заниматься управлением памятью, если язык реализует сборщик мусора, но если другого выхода нет, это просто придется сделать. Так, например, в случае с PHPExcel это просто необходимо при его использовании в версиях до 5.3. Он просто ОЧЕНЬ прожорливый до памяти. На один прайс-лист может до 100Мб отъедать. Не всегда это приемлемо.
Вы никогда не пробовали с помощью PHPExcel генерировать несколько больших xls файлов подряд?
Пробовал, ой как пробовал… Другой баг (потеря форматирования при генерации нескольких документов) в используемой нами версии PHPExcel заставил вынести генерацию в отдельный процесс — что решило и вопрос утечек.
Попробуйте следующий кусочек кода:
Плохой пример, нет у вас там циклических ссылок. Вот вам другой пример:
<?php
class A
{
public $me = null;
public function __construct()
{
$this->me = $this;
}
public function __destruct()
{
var_dump(__METHOD__);
}
}
$q = new A;
$q = null;
flush();
echo "done\n";
flush();
Деструктор вызывается не сборщиком мусора, а тогда, когда я принудительно обнуляю ссылку. И счетчик ссылок для объекта уменьшается соответственно.
Деструктор не вызывается когда вы обнуляете ссылку. Деструктор вызывается по достижении 0 счетчиком ссылок.
Соответственно, потеряв ссылку на зацикленный граф объектов в случае отключенного gc вы получаете утечку. gc как раз и занимается отловом и уничтожением таких потерянных кластеров.
Да, совершенно верно. Меня смутила дока «This function is currently not documented; only its argument list is available.» на gc_enable. Даже и не посмотрел, что он активен по умолчанию.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ООП практикум в PHP5: Анализ ошибок, преимуществ и недостатков двух различных реализаций примесей в PHP