Comments 114
Почти убедили
Да знаем, знаем. Но любить не перестанем. :)
Таки раскукожил код…
пойду сейчас курну что пожжеще и чегонить сюда на boost вывал. Вот где шаманство — так это там
UFO just landed and posted this here
еще в PHP нет поддержки utf-8 на уровне ядра, этот аспект Вы, как мне показалось, тоже пропустили?
а как вам такое?
Fatal error: Exception thrown without a stack frame in Unknown on line 0
Fatal error: Exception thrown without a stack frame in Unknown on line 0
Ха, названия функций — еще не вся бяда… те же строковые функции могут возвращать false, '', 0, -1 при отрицательном результате выполнения. Просто так повелось.
С опытом напрягает это все меньше и меньше. Но. Иногда хочется, чтобы настал такой момент, например к выходу PHP6 — хрен с ней с обратной совместимостью — чтобы причесали все названия функций и логику того что они возвращают.
С опытом напрягает это все меньше и меньше. Но. Иногда хочется, чтобы настал такой момент, например к выходу PHP6 — хрен с ней с обратной совместимостью — чтобы причесали все названия функций и логику того что они возвращают.
UFO just landed and posted this here
Ох, а я уж лучше с синтаксисом повожусь. тем более что функции str_* и array_* нечасто использую, можно и мануал почитать.
oArray — я не сразу понял что имеется ввиду =)
Тогда уж для класса oString метод get() не нужен, есть «волшебный» __toString()
oArray можно смело отправлять в топку. Все равно гибкости обычным массивам не добавляет, а для оопшности можно и STL-евские обертки поюзать
$_COOKIE!!!
это типа вместо Smokie!!! (фильм «Маска»©)?
Начало неплохое.
Неплохо бы интегрировать с Spl Types
К недостатком кода нужно отнести отсутствие интеграции с стандартными интерфейсами.
Посмотрите например на сlass ArrayIterator с пакета Spl.
ИМХО: юнит тестов нехватает, вообщем пялить и пялить :).
Неплохо бы интегрировать с Spl Types
К недостатком кода нужно отнести отсутствие интеграции с стандартными интерфейсами.
Посмотрите например на сlass ArrayIterator с пакета Spl.
ИМХО: юнит тестов нехватает, вообщем пялить и пялить :).
Зачем писать ruby-style на PHP? Чисто ради эксперимента?
Если так не нравится пхпшная каша из функций, не мучайтесь и пишите на RoR.
Если так не нравится пхпшная каша из функций, не мучайтесь и пишите на RoR.
jQuery на php? Или нет?
Ну есть в запасе PHP класс для работы с jQuery:
anton.shevchuk.name/php/php-library-for-jquery/
anton.shevchuk.name/php/php-library-for-jquery/
Оффтоп, конечно, но библиотека клевая и полезная. Любителям ZF <=1.6.x смотреть сюда: jquery.hohli.com/zf.html. Продвинутым (ZF >=1.7.x) смотреть сюда: framework.zend.com/manual/en/zendx.jquery.html
ноги несомненно растут от туда :)
Не, не думаю. Если бы это был jQuery на php, то нужен некий god-обжект, в который входят все вышеперчисленныве классы, и работает с соответствующим в зависимости от запроса и аргуметов методов __get, __set и __call. А так — просто пара классов и все :-)
Method chaining теперь навсегда ассоциироваться с jquery будет?
В велопарке подержанных велосипедов очередное пополнение
UFO just landed and posted this here
И… Это… ну… типа……… да…
На… всех хостингах…… ставьте……
На… всех хостингах…… ставьте……
Это тонкая ирония?
UFO just landed and posted this here
как по мне, просто торжество абсурдизма) я очень долго смеялся
UFO just landed and posted this here
нет, я действительно не думал что вы серьезно. не знаком с концепцией, которую вы упомянули. да и странным показалось упоминание каких-либо XML-технологий в топике про ООП. ни в коем случае не хотел обидеть
UFO just landed and posted this here
Раз уж вы заговорили об этом всем, как вы вообще привыкли описывать структуру XML? XML Schema, Schematron? Какие инструменты используете если не секрет?
> веб — это XHTML
Нет, веб это до сих пор (!) HTML 4, уже десять лет как (плюс припарки в виде CSS/JS). XHTML так и не получил должного распространения (и вряд ли получит: работы над XHTML2 все еще не закончены, а работы над XHTML1 уже давно прикрыты).
Да и потом, если брать XHTML, то посмотрим на другие технологии их состояние:
— SVG (переусложнен, противоречив, никому из интырпрайза нафиг не нужен)
— SMIL (кто-нибудь вообще слышал о нем? %))
— MathML (ну и где они, реализации?)
— XForms (я видел только одну реализацию для браузера: плагин в FF, но он даже под 3-ю версию не портирован...)
В этих технологиях несомненно есть хорошие идеи, но на деле они никому не нужны.
> единственные «минусы» которых — отсутствие знаний у разработчиков
Ну да, а еще:
— непоследовательность (эх, W3C...)
— отсутствие интеграции (даже несмотря на то, что XPath 2.0, XQuery 1.0 и XSLT 2.0 используют одно представление XML)
— сложность реализации
Ну и прочие «мелочи».
Нет, веб это до сих пор (!) HTML 4, уже десять лет как (плюс припарки в виде CSS/JS). XHTML так и не получил должного распространения (и вряд ли получит: работы над XHTML2 все еще не закончены, а работы над XHTML1 уже давно прикрыты).
Да и потом, если брать XHTML, то посмотрим на другие технологии их состояние:
— SVG (переусложнен, противоречив, никому из интырпрайза нафиг не нужен)
— SMIL (кто-нибудь вообще слышал о нем? %))
— MathML (ну и где они, реализации?)
— XForms (я видел только одну реализацию для браузера: плагин в FF, но он даже под 3-ю версию не портирован...)
В этих технологиях несомненно есть хорошие идеи, но на деле они никому не нужны.
> единственные «минусы» которых — отсутствие знаний у разработчиков
Ну да, а еще:
— непоследовательность (эх, W3C...)
— отсутствие интеграции (даже несмотря на то, что XPath 2.0, XQuery 1.0 и XSLT 2.0 используют одно представление XML)
— сложность реализации
Ну и прочие «мелочи».
Супер! Дано так хотелось бы со строками работать. Т.е., в symfony есть похожий класс DbFinder, который по сути стал оберткой для встроенных ORM, запросы там строятся точно так же, очень просто и красиво. Если б ещё со строками и массивами столь непренужденно работать! Жду стабильный релиз, чтоб использовать в новом проекте :)
Откройте для себя композицию функций: g o f = g(f(x)).
Как это реализовать в PHP — думайте сами.
Как это реализовать в PHP — думайте сами.
нашел в одном из файлов «// return oInteger(strlen($this->var));», да уж, не доверять функции strlen — это жестоко :)
Сильно напрягает название методов one_two, когда по всем стандартам для PHP(Zend,PEAR, etc) принято oneTwo.
А так — спасибо) Переделаю под себя под UTF-8 с нормальными именами)
А так — спасибо) Переделаю под себя под UTF-8 с нормальными именами)
Автору:
Иногда в поисках возможности создать что-то более простое, чем имеющиеся стандартные методя языка приводят к абсолютно другому результату. Это я к тому, что есть некоторая грань, которая стоит в максимальной простоте и удобности для большинства пользователей. Эта грань очень сумрачна и размыта и определяется только временем. Если есть в языке неудобные штуки — появляются заплатки, которые делают их удобными и т.д.
Всегда есть возможность сделать лучше. Абсолютно всегда. Всегда, в любую систему можно добавить новый функционал или улучшить старый. Но не всегда это нужно.
то что вы сделали конечно предполагает очень красивое написание, не спорю. Только вот можно обойтись без этого? Думаю, что да. Тем более, что если к странностям php (а такие странности в любом языке есть) привыкаешь, то уже не думаешь над названиями функций.
Вобщем, конечно красиво, но я бы не стал этим пользоваться. Потому что кроме красоты это мало что дает. Но за эту красоту надо еще заплатить 1) тем, что надо все-таки врубаться в ваши классы 2) что лишних ресурсов это чуть-чуть да сожрет. А при частом использовании может и не чуть-чуть.
Иногда в поисках возможности создать что-то более простое, чем имеющиеся стандартные методя языка приводят к абсолютно другому результату. Это я к тому, что есть некоторая грань, которая стоит в максимальной простоте и удобности для большинства пользователей. Эта грань очень сумрачна и размыта и определяется только временем. Если есть в языке неудобные штуки — появляются заплатки, которые делают их удобными и т.д.
Всегда есть возможность сделать лучше. Абсолютно всегда. Всегда, в любую систему можно добавить новый функционал или улучшить старый. Но не всегда это нужно.
то что вы сделали конечно предполагает очень красивое написание, не спорю. Только вот можно обойтись без этого? Думаю, что да. Тем более, что если к странностям php (а такие странности в любом языке есть) привыкаешь, то уже не думаешь над названиями функций.
Вобщем, конечно красиво, но я бы не стал этим пользоваться. Потому что кроме красоты это мало что дает. Но за эту красоту надо еще заплатить 1) тем, что надо все-таки врубаться в ваши классы 2) что лишних ресурсов это чуть-чуть да сожрет. А при частом использовании может и не чуть-чуть.
И еще — автодополнение кода в IDE не будет работать ;)
Как я уже говорил, данный пример и не должен использоваться в живых проектах — лишь для самообразования… (хотя некоторые элементы реализации и имеют право на существование)…
Как я уже говорил, данный пример и не должен использоваться в живых проектах — лишь для самообразования… (хотя некоторые элементы реализации и имеют право на существование)…
Даёт. Если правильно абстрагировать большинство функций то намного проще писать unit test'ы. Попробуй написать тест кода который отсылает email.
Приходит мужик к врачу.
— Здравствуйте, — говорит.
И начинает раздеваться.
Снимает рубашку, складывает её по швам, пуговки застегивает и кладет на стул.
Снимает майку, тоже складывает и укладывает рядом с рубашкой.
Ботиночки рядом поставил, носки снял, разгладил и рядом положил.
Брюки по стрелочкам и на спинку стула, трусы снимает, тоже по швам разгладил рядом с майкой положил и говорит:
— Знаете, доктор, вот посмотрите, у меня одно яичко чуть выше другого.
— Ну и что тут такого?
— Как что? Неаккуратненько как-то.
— Здравствуйте, — говорит.
И начинает раздеваться.
Снимает рубашку, складывает её по швам, пуговки застегивает и кладет на стул.
Снимает майку, тоже складывает и укладывает рядом с рубашкой.
Ботиночки рядом поставил, носки снял, разгладил и рядом положил.
Брюки по стрелочкам и на спинку стула, трусы снимает, тоже по швам разгладил рядом с майкой положил и говорит:
— Знаете, доктор, вот посмотрите, у меня одно яичко чуть выше другого.
— Ну и что тут такого?
— Как что? Неаккуратненько как-то.
Не вижу здесь той самой удивительной уличной магии со словами «В РОТ МНЕ НОГИ, КАК ТЫ ЭТО ДЕЛАЕШЬ?». С удовольствием воскликнул бы так же, но увы…
Предлагаю файлы переименовать в *.class.php.
О да, ООП как неймспейсы в лучших традициях PHP4. Вот уж действительно сила.
Своим постом вы только подтвердили убогость языка, называя ЭТО «магией ООП».
Своим постом вы только подтвердили убогость языка, называя ЭТО «магией ООП».
> вы только подтвердили убогость языка, называя ЭТО «магией ООП»
какая еще «убогость»? что за «ЭТО»? Что есть «не убогость»? Где нет «ЭТОГО»?
какая еще «убогость»? что за «ЭТО»? Что есть «не убогость»? Где нет «ЭТОГО»?
«убого» это когда называют «магией ООП» засовывание кучи функций во враппер-класс. С тем же руби автор знакомился, видимо, исключительно по статейкам аля «Блог на рельсах за 15 минут»
> С тем же руби автор знакомился, видимо, исключительно по статейкам аля «Блог на рельсах за 15 минут»
А Вы на каком уровне с Руби знакомы? Можно посмотреть сравнительные примеры «убогости» PHP и «неубогости» Ruby?
А Вы на каком уровне с Руби знакомы? Можно посмотреть сравнительные примеры «убогости» PHP и «неубогости» Ruby?
Во-первых, я сейчас даже не писал, что php — убог, а ruby — нет. Но данное «подтверждение» крутости ООП в php — это просто детский сад, тут и спорить не о чем.
Во-вторых, мне вот щас действительно не очень хочется расписывать какие-либо преимущества руби перед пхп. Если вам действительно интересно, посмотрите на рельсы, там вся эта магия руби очень основательно используется, даже слишком, благодаря чему исходники крайне запутаны, а конечные интерфейсы зачастую может и выглядит красиво, но до фига не удобны, когда хочется выйти за рамки задуманого разработчиками. Тем не менее мы сейчас говорим о возможностях языка, а он как раз позволяет делать такое. Для примера можете взглянуть на реализацию коллекций ассоциаций в рельсах и подумать как подобное можно было бы реализовать в пхп. Те кто думает что CakePHP — это «как RoR» сильно заблуждаются.
Во-вторых, мне вот щас действительно не очень хочется расписывать какие-либо преимущества руби перед пхп. Если вам действительно интересно, посмотрите на рельсы, там вся эта магия руби очень основательно используется, даже слишком, благодаря чему исходники крайне запутаны, а конечные интерфейсы зачастую может и выглядит красиво, но до фига не удобны, когда хочется выйти за рамки задуманого разработчиками. Тем не менее мы сейчас говорим о возможностях языка, а он как раз позволяет делать такое. Для примера можете взглянуть на реализацию коллекций ассоциаций в рельсах и подумать как подобное можно было бы реализовать в пхп. Те кто думает что CakePHP — это «как RoR» сильно заблуждаются.
> я сейчас даже не писал, что php — убог
«вы только подтвердили убогость языка» — habrahabr.ru/blogs/php/47785/#comment_1229894
> Те кто думает что CakePHP — это «как RoR» сильно заблуждаются.
А причем здесь какие-то Рельсы и какой-то там КейкПХП?
Вы дали четкое определение «убого» относительно ПХП: «убого» это когда называют «магией ООП» засовывание кучи функций во враппер-класс. Вот мне и интересно — где «не убого»? Определенно же — Вы должны знать ответ на этот вопрос, раз так категорично определяете «убогость» PHP. Или я ошибся?
> Для примера можете взглянуть на реализацию коллекций ассоциаций
а что за коллекции ассоциаций?
«вы только подтвердили убогость языка» — habrahabr.ru/blogs/php/47785/#comment_1229894
> Те кто думает что CakePHP — это «как RoR» сильно заблуждаются.
А причем здесь какие-то Рельсы и какой-то там КейкПХП?
Вы дали четкое определение «убого» относительно ПХП: «убого» это когда называют «магией ООП» засовывание кучи функций во враппер-класс. Вот мне и интересно — где «не убого»? Определенно же — Вы должны знать ответ на этот вопрос, раз так категорично определяете «убогость» PHP. Или я ошибся?
> Для примера можете взглянуть на реализацию коллекций ассоциаций
а что за коллекции ассоциаций?
> засовывание кучи функций во враппер-класс
а в Руби не так разве?
а в Руби не так разве?
Для меня пхп убог тем, что на него нельзя положиться. тоесть если я знаю, что мне шарп или руби выдадут вменяемое сообщение о ошибке, то в пхп черти что может быть. а чего стоит то, что пыха выполняет редирект после несловленного эксепшена… или вообще не выдать ошибки, и ты ее должен определять по каким-то косвенным признакам. Только мне все это не мешает писать на пхп. Со времен набираются наработки, на которые вполне можно положиться.
ну т.е. «убог» он, получается, в чем-то другом (относительно Ваших привычек-непривычек), а не в ООП, так?
ну, это первая строчка, который выдал поисковик в моем мозгу по запросу «убогий, пхп»:) Ну а вообще, есть некоторые вещи, которые меня слабо волнуют в ооп пхп, но все же: нужно явно вызывать отцовский конструктор при определении конструктора в классе-наследнике. То же и с деструктором. А еще не дай бог вы выбросите из деструктора иксепшн. Или вообще выбросится иксепшн при завершении скрипта. Или злостная функция unset, которая ни разу не вызывает деструктор объекта, а тупо приводит его в типу null. Или рэндомная последовательность вызова деструкторов при вызыве die().
Это все конечно мелочи, но крови попортили достаточно
Это все конечно мелочи, но крови попортили достаточно
(Звучит как «Зазузааааа!»)
Не, обертки — супер.
Но это все равно не ООП :)
Ситуация схожа с выпуском на рынок популярных китайских фейков.
Выглядит также, а пользуешься, понимаешь реальную разницу.
Но это все равно не ООП :)
Ситуация схожа с выпуском на рынок популярных китайских фейков.
Выглядит также, а пользуешься, понимаешь реальную разницу.
Ага, вот эти ребята, сейчас я покажу особую, php ООП-магию
авторы языка никакую траву не курили. а вот судя по вашему «шедевру», вы кажется употребляете тяжелые вещества :)
все эти претензии к дизайну PHP говорят лиш о низком уровне владения данным языком. вот поработаете подольше с ним (если конечно будет желание), то поймете что все эти обертки и костыли якобы для улутшения — не нужны, т.к. php уже имеет много чего встроенного.
все эти претензии к дизайну PHP говорят лиш о низком уровне владения данным языком. вот поработаете подольше с ним (если конечно будет желание), то поймете что все эти обертки и костыли якобы для улутшения — не нужны, т.к. php уже имеет много чего встроенного.
забавно, почитаем
насчет того, что в PHP до сих пор (!) (или пока?) нет стандарта на имена built-in-функций/объктов — это да, плохо (как плохо и то, что язык не чувствителен к регистру)
насчет того, что функция может «портить» аргумент, работая с ним по ссылке и никак этот факт визуально не определить — тоже плохо (например, можно было бы помечать такие имена функций знаком восклицания в конце — obj.sort!), но с другой стороны — можно посмотреть всегда документацию и уточнить такие моменты (поскольку все случаи невозможно предусмотреть и где-то нужно, чтобы функция преобразовывала объект-параметр)
насчет неинтуитивных возвращаемых значений ('', 0, false) — да, тоже бы неплохо иметь хоть какой-нибудь конвеншн, но и в других языках, я не уверен, что с этим моментом все четко
по поводу, что такое ООП-язык и что такое не-ООП-язык — пожалуйста, все, кто утверждает об принадлежности или непринадлежности языка к ООП — придите сюда и четко изложите свои мысли и доводы, что такое настоящий ООП язык, откуда вы эти рамки взяли и с чего, вообще, взяли, что предложенное вами определение будет верным в последней инстанции? Можно будет взять различные фундаментальные труды и их определния, соотнести, что схоже, что нет (что должно быть обязательно, что — не обязательно, и почему) и т.д. Это будет конструктивней и инстересней, нежели твердеть с деловым видом об «убожестве» чье-то, довольно мощной, разработки.
А устраивать какие-то сомнительные холиворы (не являясь при этом создатилями ни PHP, ни Ruby) — вообще какая-то ерунда.
насчет того, что функция может «портить» аргумент, работая с ним по ссылке и никак этот факт визуально не определить — тоже плохо (например, можно было бы помечать такие имена функций знаком восклицания в конце — obj.sort!), но с другой стороны — можно посмотреть всегда документацию и уточнить такие моменты (поскольку все случаи невозможно предусмотреть и где-то нужно, чтобы функция преобразовывала объект-параметр)
насчет неинтуитивных возвращаемых значений ('', 0, false) — да, тоже бы неплохо иметь хоть какой-нибудь конвеншн, но и в других языках, я не уверен, что с этим моментом все четко
по поводу, что такое ООП-язык и что такое не-ООП-язык — пожалуйста, все, кто утверждает об принадлежности или непринадлежности языка к ООП — придите сюда и четко изложите свои мысли и доводы, что такое настоящий ООП язык, откуда вы эти рамки взяли и с чего, вообще, взяли, что предложенное вами определение будет верным в последней инстанции? Можно будет взять различные фундаментальные труды и их определния, соотнести, что схоже, что нет (что должно быть обязательно, что — не обязательно, и почему) и т.д. Это будет конструктивней и инстересней, нежели твердеть с деловым видом об «убожестве» чье-то, довольно мощной, разработки.
А устраивать какие-то сомнительные холиворы (не являясь при этом создатилями ни PHP, ни Ruby) — вообще какая-то ерунда.
опечатки:
— чье-то => чьей-то*
— создатилями => создателями*
— чье-то => чьей-то*
— создатилями => создателями*
да и, у кого возникнет ощущение, что я отстаиваю PHP, оносительно других языков (Python, Ruby), скажу, что в настоящий момент уже давно не пишу на PHP, а занимаюсь только JavaScript'ом (и вместе с тем, Python и Ruby (их я практикую для себя, в свободное от работы время) мне нравятся больше, чем PHP); поэтому — я не отстаиваю PHP и его идеологию, мне просто интересна тенденция цепной реакции и холиворов на этой почве.
ООП оно неуловимо, как Джо.
Настоящее ООП, по всей видимости, присутствует только в Smalltalk, но и там основным элементом является посылка сообщения, а не объекты, хе-хе.
Настоящее ООП, по всей видимости, присутствует только в Smalltalk, но и там основным элементом является посылка сообщения, а не объекты, хе-хе.
oMG()
Автор не думает об оптимизации, а только усложняет код излишними классами.
Фтопку.
Фтопку.
Осталось только узнать, сколько скорости при этом теряем, а так каждый сам себе хозяйн.
Меня устраивают и базовые функции php (как названия, так и return'ы — привыкнуть можно)
Меня устраивают и базовые функции php (как названия, так и return'ы — привыкнуть можно)
По-моему, про сеттеры и геттеры писать было излишне. В любой книжке, где упоминается ООП (включая, наверное, практически любой ман по PHP), пишется, что доступ к свойствам объекта лучше осуществлять как раз через геттеры/сеттеры.
Или я тут чего-то очень интересного/удобного не заметил (добавление восклицательных знаков и ucfirst не в счет, думаю, и так понятно, что в геттере/сеттере можно обрабатывать значения)?
Мне кажется, интереснее было бы написать о реализации «виртуальных» геттеров, например. Ну это так…
Или я тут чего-то очень интересного/удобного не заметил (добавление восклицательных знаков и ucfirst не в счет, думаю, и так понятно, что в геттере/сеттере можно обрабатывать значения)?
Мне кажется, интереснее было бы написать о реализации «виртуальных» геттеров, например. Ну это так…
оч много здравого в статье
ка-то на пхп-Клубе высказался, что согласно классификации Буча, пхп не явл объектно-ориентированным языком. Объектным — да… за что был закидан помидорами.
ка-то на пхп-Клубе высказался, что согласно классификации Буча, пхп не явл объектно-ориентированным языком. Объектным — да… за что был закидан помидорами.
Sign up to leave a comment.
PHP и магия ООП