Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 122
оно то все конечно хорошо, но правило Деметры гласит «Объект А может вызывать любые из собственных методов. Если он создает Объект В, он может вызывать любые методы Объекта В, но ему не следует вызывать методы объектов, возвращаемых Объектом В»
у вас в примере оно явно не применялось ;)
у вас в примере оно явно не применялось ;)
не сразу понял, о чём вы, но прочитал еще раз.
то есть если Map вызывает цепочку методов и в одном из них возвращается Стринг, то надо начинать новую цепочку?
ну, моя либа не заставляет нарушать правило Деметры) она даёт только функционал, а вы уже сами распоряжайтесь тем, как его правильно применить и оформить)
то есть если Map вызывает цепочку методов и в одном из них возвращается Стринг, то надо начинать новую цепочку?
ну, моя либа не заставляет нарушать правило Деметры) она даёт только функционал, а вы уже сами распоряжайтесь тем, как его правильно применить и оформить)
кажется, будет убийственная нагрузка. считали использование памяти при обработке большого количества данных в цикле?
прикинул приблизительный оверхед:
то есть, серьёзная разница есть только в классе Number. Хотя greedykid подсказал, что там есть отличное место для уменьшения потребления памяти на четверть (перевод protected $convert в protected static $convert). Уверен, что если занятся оптимизацией, то можно значительно уменьшить и так незначительный оверхед.
Хотя, на самом деле те проценты, которые вспыли сейчас в масштабах приложения будут намного меньше)
<?
$memStart = memory_get_usage();
$array = array();
for ($i = ; $i < 10000; $i++) {
$array[] = str_repeat("1234567890", 100); // 11386324
$array[] = o(str_repeat("1234567890", 100)); // 14636048
$array[] = 1234567890; // 1106060
$array[] = o(1234567890); // 4997708
$array[] = range(1, 100); // 111109932
$array[] = o(range(1, 100)); // 114599440
}
echo memory_get_usage() - $memStart;
то есть, серьёзная разница есть только в классе Number. Хотя greedykid подсказал, что там есть отличное место для уменьшения потребления памяти на четверть (перевод protected $convert в protected static $convert). Уверен, что если занятся оптимизацией, то можно значительно уменьшить и так незначительный оверхед.
Хотя, на самом деле те проценты, которые вспыли сейчас в масштабах приложения будут намного меньше)
Вы не учли, что подключаемые классы Number, String и т.д. занимают дополнительную память (и время), даже если экземпляров этих классов не созданы.
ИМХО у данной библиотеки есть шанс только как расширение, тогда это действительно будет удобно.
ИМХО у данной библиотеки есть шанс только как расширение, тогда это действительно будет удобно.
Да, подключение всей библиотеки занимает около 304 Кб в памяти.
Впрочем, способы с этим справиться известны — для этого есть акселераторы
Впрочем, способы с этим справиться известны — для этого есть акселераторы
И в силу особенностей php SAPI эти классы будут подключаться и создаваться при каждом запросе!
У меня есть опыт разработки экстеншенов, впринципе плевое дело перенести эту либу на си.
Могу начать, так сказать подготовить плацдарм, дальше уж сами.
Как у экстеншена, у нее действительно больше шансов.
А вообще, если честно, выглядит как попытка сделать из г**на конфетку. PHP такой какой он есть, и в этом его плюс.
Если нравится такой стиль, то может лучше слезть с PHP?
Без обид…
Могу начать, так сказать подготовить плацдарм, дальше уж сами.
Как у экстеншена, у нее действительно больше шансов.
А вообще, если честно, выглядит как попытка сделать из г**на конфетку. PHP такой какой он есть, и в этом его плюс.
Если нравится такой стиль, то может лучше слезть с PHP?
Без обид…
Интересная идея, пока не уверен что оно того стоит, но все же можно присмотреться.
Супер! Этого реально не хватает в php, но это всё должно быть на уровне ядра =(
Вот для этого-то и нужно делать расширение PHP.
Тогда и overhead будет минимален, и использовать библиотеку будет не менее удобно.
Тогда и overhead будет минимален, и использовать библиотеку будет не менее удобно.
нууу. если будет пользоваться популярностью — появится расшиение на Си, а это будет вполне близким к «на уровне ядра». И, как уже было сказано в статье, не проблема будет использовать, так как пока хватает мощности обычного виртуального хостинга — используем библиотеку на пхп, а как только проект станет более-менее популярным, тут можно уже и сервер с пропатченным пхп взять, а переписывать ничего не придётся.
На уровне ядра это вряд ли будет реализовано из-за совместимости со старыми версиями, с ArrayIterator это было возможно, со String потенциально тоже ( __toString() ведь есть), но не с числами и прочими сущностями. Нужна переделка базисных принципов языка, и тогда это уже будет не php, а Ruby
Какие базисные принципы языка, о чем вы? :)
Нужно абсолютно то же самое, что есть сейчас — но написанное на C, а не на PHP.
Т.е. проблема исключительно в производительности, но не в интерфейсах.
Нужно абсолютно то же самое, что есть сейчас — но написанное на C, а не на PHP.
Т.е. проблема исключительно в производительности, но не в интерфейсах.
имеется ввиду число есть число а не объект как в том же Руби, это касается самого ядра и принципов по которым все пишется. Я ничего не имею против того что бы сделать расширение для пхп и использовать дополнительную функциональность, но зачем? В данном ключе сам язык такой какой есть, и если это не нравится, выбираем другой и пишем уже на нем. Хотите объекты везде — берите Java или Ruby, в чем проблема. Видите плюсы в использовании конкретно пхп — используйте его так как он есть, не придумывая велосипед по 10му разу, зачем плодить неразбериху в сущностях, когда эти самые сущности уже давно описаны и используются в контексте языка так, как задумали разработчики. Я не думаю что они не в курсе что можно использовать числа как экземпляры класса «число», и что есть такая вещь как перегрузка операторов и т.д. Просто это не нужно для самого ПХП в большинстве случаев и незачем нагружать и без того гибкий язык лишней для него мишурой
*Currency
code.google.com/p/obj-php/source/browse/examples/KurrencyKonverter.php
смотрите коммент перед названием)
смотрите коммент перед названием)
А что это меняет? =) Почему написали неправильно умышленно?
Не понял, а почему тогда неправильно называете?
наверное, по той же причине, что и Konqueror, Krusader, Kompare, KolourPaint и множество остальных программ ;) я заядлый КДЕшник до глубины души и тащусь от этой идеи замены первой буквы)
В таком случае разумно делать свой собственный KDE edition, а не вводить в заблуждение людей, которые будут пользоваться библиотекой. Ведь среди них могут быть ярые поклонники гнома, например. Халивар?
КуренсиКонвертор не есть одним из базовых классов библиотеки, а только демонстрационный. Я надеялся, что у программистов есть немножко чувства юмора.
Я никому не навязываю свои взгляды на DE.
Я никому не навязываю свои взгляды на DE.
Чувство юмора относительно названий классов исчезает после первого же написанного приложения с ~50 сущностями внутри )
Точно =)
Бросьте, это всего лишь один класс в папке «examples», который можно переименовать как угодно — изменив только одну строку. :)
поверьте, я писал такие приложения. есть случаи когда можно пошутить. есть случаи, когда надо обойтись без шуток. Это не тот случай. Вы просто ищите к чему придраться.
GurrencyGonvertor
проста такъ прекольна песать, да?
Чувствую, что вдохновлялися библиотекою jQuery; это прекрасно.
Да, PHP не хватает аналога .NET LINQ для коллекций, это правильный путь :)
Кстати, имхо, лучше сделать ceil() и floor(), которые используют round(). Понятнее будет.
Какой кошмар! А стандартным способом программировать уже не модно? Нужно везде пихать идею как в jQuery?
уверен, во времена царствования асма, когда только появлялись более высокоуровневые языки программирования — говорили точно так же
В jquery ну пытались ECMAscript изнасиловать. Добавили удобства и кроссбраузерности. А ради чего этот огород в PHP до сих пор не понятно? Подобные библиотеки появлялись и обсуждались со времен выхода PHP4 с разным успехом. Только вот не об одной такой пока широкому кругу не известно…
Даже если напишет кто-нибудь либу на C++, будет весело смотреть на переписку с техподдержками шарахостов ))) Им то глубоко параллельно, что вы тут хотите полезную вещь для тестов запустить…
Да и в PHP такая абстракция ни к чему… просто язык такой, какой есть. А чтобы в функциях не путать, пользуйтесь справочниками. А учить новый синтаксис старых функций мне не хочется. Пусть лучше все остается, как было.
А если охото чисто на объектах писать, Вам уже предложили другие языки, где все это реализовано.
Даже если напишет кто-нибудь либу на C++, будет весело смотреть на переписку с техподдержками шарахостов ))) Им то глубоко параллельно, что вы тут хотите полезную вещь для тестов запустить…
Да и в PHP такая абстракция ни к чему… просто язык такой, какой есть. А чтобы в функциях не путать, пользуйтесь справочниками. А учить новый синтаксис старых функций мне не хочется. Пусть лучше все остается, как было.
А если охото чисто на объектах писать, Вам уже предложили другие языки, где все это реализовано.
Пользуйтесь, пользуйтесь справочником. А я, не затрагивая эту реализацию, скажу, что буду пользоваться рациональным API дешевой обертки — так удобнее, чем каждый раз лезть в справочник, потому что забываешь как работает функция, из-за того, что ее интерфейс уродлив.
вы будете пользоваться справочником чаще:
— справочник функций
— справочник библиотеки
— справочник функций
— справочник библиотеки
phpDoc мне в помощь ))
а остальное я и так запомню… + я оборачиваю не только интерфейс но и реализацию… Те же mb_* с аналогами обернуты, например.
а остальное я и так запомню… + я оборачиваю не только интерфейс но и реализацию… Те же mb_* с аналогами обернуты, например.
да я уверен вы и основные функции прекрасно помните :)
только вы помните 2 библиотеки и получаете растраты по размеру кода/памяти. Вы не получаете ничего, кроме красивого кода + исключения при не нетиповых операций.
Мы все мнесте это проходили на соотв. операторах C++, спасибо увольте. Всегда проще сменить язык.
Повторю, ваш код возможно (!) станет проще для понимания, но вы и так в силах делать его понятным и простым :) В приведенном примере ничего кроме ужаса возникать не должно. Как легко мы от строки ушли в сторону целого, кажется мы поступили точно также как и в обычном php:
только вы помните 2 библиотеки и получаете растраты по размеру кода/памяти. Вы не получаете ничего, кроме красивого кода + исключения при не нетиповых операций.
Мы все мнесте это проходили на соотв. операторах C++, спасибо увольте. Всегда проще сменить язык.
Повторю, ваш код возможно (!) станет проще для понимания, но вы и так в силах делать его понятным и простым :) В приведенном примере ничего кроме ужаса возникать не должно. Как легко мы от строки ушли в сторону целого, кажется мы поступили точно также как и в обычном php:
->insert('[вставлено]', 5)
->length() // Number
->multiply(4)
->add(6, 9, new Number(15))
Еще раз скажу, что эту реализацию я не рассматривал. Я оспорил мнение о справочниках.
Я про справочники вообще между словом написал. Пользуюсь эклипсом с кодассистом и в справочник только по жизненной необходимости влезаю.
Смысл-то в том, что PHP-это процедурный язык с поддержкой ООП, а не объектный, как джава или руби и т.п.
Если начать какой-нибудь проект, основанный на данной библиотеке классов, то можно получить неизлечимые тормоза и трудночитаемый код (мне так довольно тяжело было проследить всю цепочку). А смысла в этом не на грош. Не спорю, что запрограммировать строку в пару десятков методов круто… только кто в ней будет разбираться через пол года… мозг себе сломает.
При проектировании библиотеки не было изобретено ничего нового. Если так не нравится PHP, используйте что-нибудь другое. Благо помимо пхп и перла ещё туева хуча языков, в основе которых уже реализованы объекты. Альтернатива есть.
Это не javascript, которому, собственно, альтернатив особо не намечается… (Flash или Java не в счет)
Лучше абстрагируйте то, что действительно нужно и касается конкретного проекта. А базовые типы оставьте уже в покое. Они на то и базовые.
Смысл-то в том, что PHP-это процедурный язык с поддержкой ООП, а не объектный, как джава или руби и т.п.
Если начать какой-нибудь проект, основанный на данной библиотеке классов, то можно получить неизлечимые тормоза и трудночитаемый код (мне так довольно тяжело было проследить всю цепочку). А смысла в этом не на грош. Не спорю, что запрограммировать строку в пару десятков методов круто… только кто в ней будет разбираться через пол года… мозг себе сломает.
При проектировании библиотеки не было изобретено ничего нового. Если так не нравится PHP, используйте что-нибудь другое. Благо помимо пхп и перла ещё туева хуча языков, в основе которых уже реализованы объекты. Альтернатива есть.
Это не javascript, которому, собственно, альтернатив особо не намечается… (Flash или Java не в счет)
Лучше абстрагируйте то, что действительно нужно и касается конкретного проекта. А базовые типы оставьте уже в покое. Они на то и базовые.
Правильно, давайте сборщик мусора посильнее нагрузим, а то стоит без дела.
Даешь замусоривание памяти огрызками объектов как в Java! :-)
Даешь замусоривание памяти огрызками объектов как в Java! :-)
Ньюансы: www.gramota.ru/slovari/dic/?lop=x&efr=x&zar=x&ag=x&ab=x&sin=x&lv=x&az=x&pe=x&word=%ED%FE%E0%ED%F1
Исправьте плз, глаз режет.
Насчет библиотеки: думаю, найдутся люди, которым такая штука покажется полезной. Лично я — за использование старых проверенных методов. Они хорошо документированы и код вылизан поколениями разработчиков PHP. В вашем творении, несмотря на 80% покрытия тестами — такой уверенности нет.
Исправьте плз, глаз режет.
Насчет библиотеки: думаю, найдутся люди, которым такая штука покажется полезной. Лично я — за использование старых проверенных методов. Они хорошо документированы и код вылизан поколениями разработчиков PHP. В вашем творении, несмотря на 80% покрытия тестами — такой уверенности нет.
естественно. в любом новом творении уверенности нету. но это не причина, чтобы не писать и не использовать ничего нового. более того, если бы все мыслили так инертно: «лучше проверенное, но старое», кто знает, на какой ветке мы бы сейчас сидели? ;)
но это же ваше утверждение запрещает вам говорить:
Принимаю восторженные отзывы и конструктивную критику :)
Конечно на любителя и на задачу, но я пока оборачиваю только строки и даты. Большее не представляло надобности.
Спасибо, идея хорошая.
Самое главное тут не в том, что можно делать красивые цепочки как в jQuery.
Самое главное тут в том, что код вызывает исключения! Да-да, наконец-то, в 2009 году на PHP может быть реализована грамотная модель обработки ошибок при работе с примитивами!
А то, честно говоря, надоело уже держать в голове все эти возможные варианты возвращаемых значений, когда одни встроенные функции возвращают -1, другие 0, третьи не-0, какие-то false, какие-то NULL… и я думаю, не один я такой. За что автору, конечно, респект.
Ждем релиза ;)
Самое главное тут не в том, что можно делать красивые цепочки как в jQuery.
Самое главное тут в том, что код вызывает исключения! Да-да, наконец-то, в 2009 году на PHP может быть реализована грамотная модель обработки ошибок при работе с примитивами!
А то, честно говоря, надоело уже держать в голове все эти возможные варианты возвращаемых значений, когда одни встроенные функции возвращают -1, другие 0, третьи не-0, какие-то false, какие-то NULL… и я думаю, не один я такой. За что автору, конечно, респект.
Ждем релиза ;)
действительно, перевести всё на исключения — было одной из целей. правда, пока исключения оно возвращает только кое-где. но это вопрос времени ;)
спасибо) но я все-же надеюсь, что оупен-сорс-сообщество подключится и тогда дело пойдёт быстрее, интереснее и продуктивнее)
спасибо) но я все-же надеюсь, что оупен-сорс-сообщество подключится и тогда дело пойдёт быстрее, интереснее и продуктивнее)
опять же вопрос совместимости
Какой совместимости? С чем?
со страрыми версиями кода. Вот обновилась версия пхп на сервере и приложение легло, потому что исключения там не обработаны. И это был бы даже не варнинг, а полное падение всего
новые функции с последовательным названиями, выбросом исключений и остальными прелестями вполне можно было бы выделить в отдельные неймспейсы: \array\ *, \string\* и т.д.
а хендлеры на необработанные исключения надо ставить, тогда сразу все в логах видно будет.
только уже работающему проекту это не поможет. Он все равно ляжет, смотри ты в логи или не смотри. И скорее всего так оно будет даже при правильно написаном коде, где в какой-то функции при сторонней ошибке отдается false, а не кидает эксепшн. Придется добавлять кучу try/catch в самых неожиданых местах, потому что проект писался по документации старой версии пхп, а не по новой. Единственный выход это оставить поддержку старых функций как есть, а новые с исключениями выделить в другой нэймспейс
Хорошая работа!
Правда мне кажется Rubyсты тут смеются :)))
Правда мне кажется Rubyсты тут смеются :)))
статичные курсы в конвертере валют… Никто ничего не заметит, только в конце месяца просто изнасилуют. Может даже посадят…
Мне кажется излишняя библиотека, хотя бы потому что она предназначена больше для удобства читаемости и красоты кода, но хороший программист и так читаемо код пишет, а плохой да же с этой библиотекой коряво всё сделает.
Ну это только моё мнение конечно.
Ну это только моё мнение конечно.
Ну я бы сказал ничего нового и нет, длинные цепочки вызовов, невозможность человеческой отладки, если есть глюк в одном из методов, то не представляю как его найти обычным дебагером. Тупо заходить во все методы подряд и их трассировать? Это жестоко. Да, в применении к одному типу может и нормально, но с другой стороны, зачем нам писать конструкции типа
$n = new Int(5); $n->Add(5)->Mul(10)->Sub(15);
тогда как
$n = ($n +5) * 10 — 15 читабельнее
со строками возможно и нормально, но такой подход все равно не даст всех возможностей, вот как например заменить содержимое строки между второй и третьей точкой (заменять регекспом это жестоко, а если надо обработать десятки и сотни тысяч строк), все равно уже придется искать позицию, писать в отдельные переменные и потом использовать.
Не вижу будущего у подобного проекта из-за нагрузки, из-за лишних объектов и лишней используемой памяти, из-за необходимости писать обертки для всех стандартных функций, чтобы иметь возможность нормальной работы.
Да и без правила Деметры вообще невозможно понять где и когда с каким объектом ведется работа, получается просто каша.
$n = new Int(5); $n->Add(5)->Mul(10)->Sub(15);
тогда как
$n = ($n +5) * 10 — 15 читабельнее
со строками возможно и нормально, но такой подход все равно не даст всех возможностей, вот как например заменить содержимое строки между второй и третьей точкой (заменять регекспом это жестоко, а если надо обработать десятки и сотни тысяч строк), все равно уже придется искать позицию, писать в отдельные переменные и потом использовать.
Не вижу будущего у подобного проекта из-за нагрузки, из-за лишних объектов и лишней используемой памяти, из-за необходимости писать обертки для всех стандартных функций, чтобы иметь возможность нормальной работы.
Да и без правила Деметры вообще невозможно понять где и когда с каким объектом ведется работа, получается просто каша.
согласен, все гениальное — просто
усложнение без причины — необоснованная трата ресурсов
усложнение без причины — необоснованная трата ресурсов
если есть глюк в одном из методов, то не представляю как его найти обычным дебагером.
Достаточно вызвать метод dump после соответствующего метода:
<code>$object ->method1() ->dump() ->method2() ->dump();</code>
$n = ($n +5) * 10 — 15 читабельнее
это уже обсуждалоь на php.ru, Посмотрите, там показан вполне более читабельный код
Честно говоря не понимаю, что прям уж такого в этом подходе, ведь в php строки (и другие типы) не объекты и в многих других языках также. Роль методов выполняют функции, а то порой бывает каша из функций и методов в некоторых языка, которые используют такую парадигму.
Пусть меня заминусует но лично мое IMHO что все это не нужно PHP, хотите таких красивостей пишите на Ruby на Java. Может я конечно не понимаю чего.
Ой, у дураков мысли сходятся:
habrahabr.ru/blogs/php/47785/
habrahabr.ru/blogs/php/47785/
Интересно, многие IDE смогут показать автокомплит начиная с третьей стрелочки и дальше? Или вместо того, чтобы помнить что возвращают стандартные функции php теперь нужно запомнить объект какого класса каждая из функций каждого из Ваших классов возвращает? А, и если нет автокомплита — еще нужно запомнить все функции каждого из классов.
угу, уже вижу толпу пихопепрограммистов атакующих админов чтобы последние установили ваше расширения у себя на серверах.
Пока человек хостится на виртуальном хостинге он использует либу на пхп. Как только проект переходит в более серьёзное состояние — на _свой_ сервер устанавливается пхп с расширением
полностью согл,
свое мнение на счет расширения — двумя комментами ниже…
свое мнение на счет расширения — двумя комментами ниже…
Пока человек хостится на виртуальном хостинге, его сайт будет висеть в блоке за превышение лимита используемых ресурсов. Или вообще страницы не будут успевать генериться )))) Такого уже насмотрелись…
из-за увеличения расхода памяти на 3%?
Когда напишешь, например, CMF, в которой все базовые типы будут через этот класс описаны, посмотрю, какие там будут 3 %, ага… А когда надо будет обработать массив из несколько десятков тысяч значений? Так не тестировали? Причем каждый элемент массива — тоже массив…
Я рад, что вы поразмяли свои мозги и написали этот класс… вам кажется, что совершили чудо… но об этом думали почти все, на определенном этапе изучения PHP… и приходили к выводу, что такое абстрагирование абсолютно не нужно!!!
Скоро выйдет PHP 6 и ваш класс окажется бесполезным…
Я рад, что вы поразмяли свои мозги и написали этот класс… вам кажется, что совершили чудо… но об этом думали почти все, на определенном этапе изучения PHP… и приходили к выводу, что такое абстрагирование абсолютно не нужно!!!
Скоро выйдет PHP 6 и ваш класс окажется бесполезным…
[irony]PHP ещё на шажок приблизился к python[/irony]
хотим сделать монстра из PHP
круто, особенно если будет в виде расширения.
То что сейчас имеем в стандартной библиотеке php — леденящий душу полярный зверёк.
То что сейчас имеем в стандартной библиотеке php — леденящий душу полярный зверёк.
Array_Object ещё и ужасно медленный в некоторых местах, хотя и написан на Си — переписав его на php я получил двадцатикрастный прирост производительности в foreach!
скажу одно очень понравилось, полезная штука, вот если бы расширением.
А где обертки для null, bool, float и resource? ;-)
Из говна конфетку?
Хотите TypeHinting и нормальные названия — возьмите java. Получите ещё и прекрасный рефакторинг в IDE.
Хотите TypeHinting и нормальные названия — возьмите java. Получите ещё и прекрасный рефакторинг в IDE.
ООП — это хорошо, но с библиотекой получается уродливо и некрасиво, так как в php изначально довольно неряшливый синтаксис (видимо из-за скриптовых корней языка). Вот если бы синтаксис как в Руби…
Жив ли ещё проект?
Интересно было бы скрестить его с github.com/nikic/scalar_objects/
Интересно было бы скрестить его с github.com/nikic/scalar_objects/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Object-oriented PHP