Форум: Форум PHPФорум ApacheФорум Регулярные ВыраженияФорум MySQLHTML+CSS+JavaScriptФорум FlashРазное
Новые темы: 0000000
MySQL на примерах. Авторы: Кузнецов М.В., Симдянов И.В. MySQL 5. В подлиннике. Авторы: Кузнецов М.В., Симдянов И.В. Социальная инженерия и социальные хакеры. Авторы: Кузнецов М.В., Симдянов И.В. PHP 5. На примерах. Авторы: Кузнецов М.В., Симдянов И.В., Голышев С.В. Программирование. Ступени успешной карьеры. Авторы: Кузнецов М.В., Симдянов И.В.
ВСЕ НАШИ КНИГИ
Консультационный центр SoftTime

Форум PHP

Выбрать другой форум

 

Здравствуйте, Посетитель!

вид форума:
Линейный форум (новые сообщения вниз) Структурный форум

тема: Инкапсуляция в PHP

Сообщения:  [1-10]   [11-16] 

 
 автор: МммммонстеКилл   (20.02.2012 в 19:00)   письмо автору
 
   для: cheops   (20.02.2012 в 17:35)
 

> Но это реализовать можно только на уровне систем вроде IDE

Не понял. http://ru.php.net/manual/en/reflectionproperty.getdoccomment.php --- я про это.

  Ответить  
 
 автор: МммммонстеКилл   (20.02.2012 в 18:52)   письмо автору
 
   для: cheops   (20.02.2012 в 17:46)
 

А теперь речь зашла о производительности... Мы точно скоро дойдём до религии --- не долго осталось.

Так вот: существуют решения (абсолютно прозрачные для PHP-программиста), как APC, xCache, etc. --- акселераторы, которые позволяют не парсить файлы каждый раз, а пользоваться готовым байт-кодом (фактически это компиляция как в Java, C#, etc.). Помимо прочего, в фреймворках типа Symfony существует автоматическая сборка классов в один большой файл --- вкупе с акселератором это заставляет забыть о надуманной проблеме производительности.

Проблема производительности появляется практически всегда на уровне работы с СУБД, вы же должны это знать. А константное значение, связанное с парсингом, всегда можно поправить.

P.S. Чисто FYI, к ООП это, ясное дело, ну никак не относится.

  Ответить  
 
 автор: МммммонстеКилл   (20.02.2012 в 18:46)   письмо автору
 
   для: cheops   (20.02.2012 в 17:35)
 

> Будто вы не обобщаете

Говорю про вас, утверждаю, что существуют такие-то решения --- я не вижу обобщений. У вас матан был?

> Я говорю что ООП в PHP дрянь (его недостатки перекрывают достоинства), идет возражение, нет не дрянь, точнее дрянь, но не такая дрянь, которую вы имели в виду

Я возражал совсем не против этого утверждения, я возражал против обобщения того, что все лезут в код --- это неправда (абсолютно все мои знакомые используют phpDoc для того, чтобы не лезть в код --- это непосредственно связанные между собой темы). Факт: не все лезут в код, даже если phpDoc вам кажется неудобным --- это не отменяет этого факта. Это единственное, с чем я изначально не согласен.

Если вы начнёте меня спрашивать про политику или религию, то я не сомневаюсь, что вы найдёте ещё достаточно много мнений, перпендикулярных вашим. Я не советую --- это пустая трата времени.

P.S. Весь наш разговор начинается сводится к тому, что я оправдываюсь: "нет, я это не говорил" --- желательно прекратить видеть в моих утверждениях то, чего там нет.

  Ответить  
 
 автор: cheops   (20.02.2012 в 17:46)   письмо автору
 
   для: МммммонстеКилл   (20.02.2012 в 17:09)
 

Возможно я не очень понятно выражаюсь... когда я пишу "Отсутствие этого в PHP не вероятно бесит, почти весь ООП-код бесполезен" я имею в виду вот что. ООП-модель PHP побуждает разработчика создавать развитую модель коротких классов, увязанных в иерархию. Однако, реализация такова, что чем меньше этих файлов, тем лучше, т.е. с точки зрения производительности нужны длинные файлы (а разрабатывать их неудобно, класс дробить нельзя). Да, конечно, взялся за ООП, прекращая думать об эффективности - ООП организует код, а не гарантирует какие-то другие преференции. Однако, PHP, это язык, который интенсивно используется в Web с одной стороны (много клиентов одновременно, большое потребление памяти и ресурсов) и крайне медленный сам по себе с другой. Все это не способствует развитию ООП в PHP, да и вообще PHP как языка крупных проектов, где ООП обычно и применяется. Если вам потребовался ООП и вы понимаете зачем, скорее всего у вас крупный проект. Если у вас крупный проект, зачем вы ориентируетесь на PHP? Сервера лишние? Или как Facebook хотите потом компилятор писать? Это понимают и другие разработчики, поэтому весь ООП код он либо заимствован из других языков (в которых решаются проблемы отсутствующие в PHP), либо написан людьми, которые сами не очень верят в необходимость ООП на PHP, либо которые не очень понимают ООП.

PS Да я согласен, PHP развивается, но фундаментальные недостатки никуда не деваются и чем больше проходит времени тем сложнее их исправить. Разработчикам же прикладного ПО проще сменить язык, чем изображать "хорошую мину" при "Но PHP я не люблю".

  Ответить  
 
 автор: cheops   (20.02.2012 в 17:35)   письмо автору
 
   для: МммммонстеКилл   (20.02.2012 в 17:09)
 

>Смиритесь с тем, что существуют отличные от вашей точки зрения --- не стоит так раздражаться.
Да это я понимаю и принимаю, меня раздражает, что я никак не могу уловить точку зрения. Я говорю что ООП в PHP дрянь (его недостатки перекрывают достоинства), идет возражение, нет не дрянь, точнее дрянь, но не такая дрянь, которую вы имели в виду. Это и не понятно.

>Вы застряли в прошлом, сегодня существует множество решений для облегчения жизни PHP-
>программистам.
Будто вы не обобщаете :) Да конечно, существуют решения (их на PHP слишком много), однако, существуют и другие языки, в которых можно не использовать костыли. Пусть существуют и решения для облегчения жизни PHP-программистам, я не против. Однако, если есть более удачный инструмент и я умею им пользоваться, я лучше его в руки возьму, чем будут бороздить Интернет в поисках "практически части языка", которая в язык не входит :)))

>рефлексия в PHP
Это есть, тут даже не в phpDoc дело, а в том, что рефлексия действительно стандартна и позволяет выделить интерфейс класса. Но это реализовать можно только на уровне систем вроде IDE, т.е. если вы не пишите систему сопоставимую по объему, где код, обслуживающий рефлексию будет занимать лишь несколько процентов проекта, тогда да. Если у вас обслуживание ООП-модели будет занимать 50% проекта, может ну-ка нафиг такую модель?

  Ответить  
 
 автор: МммммонстеКилл   (20.02.2012 в 17:09)   письмо автору
 
   для: cheops   (20.02.2012 в 16:25)
 

Безусловно, PHP изначально спроектирован неудачно. Но не я упомянул javaDoc, не я начал некорректные обобщения. Смиритесь с тем, что существуют отличные от вашей точки зрения --- не стоит так раздражаться.

P.S. phpDoc уже стандарт де-факто, это, не побоюсь этого выражения, практически часть языка (рефлексия в PHP уже позволяет доставать doc-блоки, благодаря чему можно встраивать мета-информацию прямо в phpDoc: http://docs.doctrine-project.org/projects/doctrine-orm/en/2.0.x/reference/basic-mapping.html --- очень удобно). Вы застряли в прошлом, сегодня существует множество решений для облегчения жизни PHP-программистам.

  Ответить  
 
 автор: cheops   (20.02.2012 в 16:25)   письмо автору
 
   для: МммммонстеКилл   (20.02.2012 в 15:52)
 

>Я повторю свой вопрос: причём тут консольная утилита, "которую бы можно было сразу вешать
>на cron-задание"?
При том же при чем phpDoc: не причем. Не удобно и все. ООП-программы можно создавать вообще не пользуясь специальными возможностями языка и ключевыми словами. Однако, если объектно-ориентированная модель необходима в приложении зачастую более удобно воспользоваться другими инструментами, с более развитыми и удобными средствами, чем в PHP, который спроектирован не совсем удачно.

  Ответить  
 
 автор: МммммонстеКилл   (20.02.2012 в 15:52)   письмо автору
 
   для: cheops   (20.02.2012 в 15:24)
 

Я повторю свой вопрос: причём тут консольная утилита, "которую бы можно было сразу вешать на cron-задание"? Впрочем, судя по мату, вы отмечаете какой-то праздник. Можете не отвечать.

> Вы я так понял возражаете против этого, говоря, что не так все печально и даже наоборот с ООП в PHP все замечательно?
Терпимо. Но PHP я не люблю.

  Ответить  
 
 автор: cheops   (20.02.2012 в 15:24)   письмо автору
 
   для: МммммонстеКилл   (20.02.2012 в 15:10)
 

>Не очень понимаю: как это относится к данной теме?
Так сложилось, что PHP-приложения распространяются и используются главным образом в виде исходных кодов. В результате у вас нет байт-кода или бинарных модулей (байт-код скорее исключение, чем правило), хотите вы или не хотите вы имеете дело с исходным кодом. Так получилось, что PHP изначально не поддерживал объектно-ориентированные возможности, они были добавлены сильно позже, когда он здорово распространился и нужно было поддерживать старый код. Кроме того, ООП был заимствован почти без адаптации, если не сказать без понимания принципов ООП. Просто добавили инструменты, ну нужны они вам, нате... Как результат поддержка инкапсуляции на уровне языка PHP слабая, если не сказать никакая (особенно по сравнению с языками, которые изначально задумывались как объектно-ориентированные). Я только это и хотел сказать: раздражает необходимость самому заботится об инкапсуляции (это можно делать не только внешними инструментами, но и ООП-средствами, только платить придется временем и кодом). Вы я так понял возражаете против этого, говоря, что не так все печально и даже наоборот с ООП в PHP все замечательно? Или вы хотите какую-то другую мысль донести?

  Ответить  
 
 автор: МммммонстеКилл   (20.02.2012 в 15:10)   письмо автору
 
   для: cheops   (20.02.2012 в 15:08)
 

> Досадно, что в составе PHP нет стандартной консольной утилиты, которую бы можно было сразу вешать на cron-задание (может в PEAR что-нибудь есть, конечно, нужно порыться).

Не очень понимаю: как это относится к данной теме? Три раза в день?

  Ответить  

Сообщения:  [1-10]   [11-16] 

Форум разработан IT-студией SoftTime
Rambler's Top100
вверх

Rambler's Top100 Яндекс.Метрика Яндекс цитирования