>мне не нравится в php это модель поведения CGI у динамических страниц
Не очень понятно о чем речь. Можно поподробнее?
>странный шаблонизатор
Это Вы о чем? РНР - плохой шаблонизатор? ;)
>отсутсвие абстракций СУБД
PDO?
>единое пространство имен
Использование класссов с методами static - решает эту проблему.
>безумная каша функций без какой либо на то системы
это проблема не языка, а архитектора системы
>медленная работа самого ООП
об этом я уже спрашивал - результаты тестов?
>не использование имеющегося в наличии механизма исключений стандартными функциями
"стандартных" функций в РНР не так много, и (на сколько я помню) они все используют исключения. Что касается расширений (extension), то их не правильно рассматривать как часть РНР. Вот они еще не все переписаны с учетом механизма исключений.
>еще неплохо бы увеличить скорость
эээ... мы о какой скорости сейчас говорим?
Еще раз повторюсь - ни то, ни другое ничему не способствуют. И это придумал даже не я (к сожалению), а умные дядьки задолго до нашего с Вами разговора. Только руки и мозги программиста могут исправить ситуацию. Плюс хорошая документация.
>Под перегрузкой методов она и подразумевается.
Очень хорошее определение :)) Ну раз другого нет, то я буду понимать под перегрузкой возможность в зависимости от количества и типов переменных вызывать тот или иной метод (поскольку часто перегрузкой называют то, что происходит при полиморфизме).
В таком рассмотрении перегрузка:
- есть зло, поскольку нифига не упрощает работу по поддержке кода;
- не является одним из необходимых условий для того чтобы считать язык ОО.
>Без перегрузки конструктора не обойтись в случае создания объекта с использованием каких либо входных переменных.
1. РНР слаботипизованный язык, в этом есть свои плюсы и свои минусы. Но такая особенность дает больше гибкости в написании веб-приложений. Поэтому перегрузка методов в зависимости от принимаемых типов - вообще говоря противоречит идеалогии языка.
2. Много кода - это один вызов func_get_args()?
3. Что-то мне подсказывает, что если для конструктора потребовалось передавать переменное количество параметров, то это косяки в проектировании объектной структуры программы.
>К тому же ООП в PHP не сильно быстрое.
О как. Можно результаты тестов увидеть? По моим данным, возможные задержки при ОО подходе в РНР много меньше тех, что вносят кривые руки программистов. А если все же возникает необходимость в этой экономии на спичках, то значит помочь тут может только чистый С(++), но уж никак не Ruby и не Java.
ООП само по себе не может упростить проект. Можно писать в функциональном стиле и проект будет стройный и понятный, а можно накрутить объеты так, что самая продвинутая документация не поможет разобраться. Т.е. мы в очередной раз приходим к тому, что не ООП, а мозги и руки программиста определяет степень кривости проекта. И уж точно не язык разработки.
А зачем смешивать статус задачи (по сути просто состояние в котором она находится) и то, на сколько эта задача выполнена? Имхо, много разумнее для проекта в целом применять показатель ООФ (освоенный объем функционала), каждая задача = функиональная единица. Таким образом мы получаем достаточно реальное представление о том, на сколько готов проект в целом (в тех самых %). А поскольку каждая задача оценивается по времени, необходимому для ее выполнения - мы контролируем состояние каждой задачи (когда она должна быть выполнена и на сколько реально выполнение задачи в этот срок). Т.е. мы видим, что совсем нет необходимости скрывать под статусом задачи % ее выполнения. Есть еще не очевидный плюс - нет различий в понимании что за статусом, например, "Почти готова" скрывается 50% или 98%.
>Договор с физ. лицом вызывает меньше доверия, чем такой же договор с ООО.
это не правильные пчелы, и они делают не правильный мед :) все зависит от человека-разработчика, от отношения к нему. если он не смог произвести впечатления и внушить доверия, то никакие договора не помогут.
>они просто бросали не закончив
собственно теже проблемы - человеческие отношения. а договор как раз и призван упорядочить отношения в критических ситуациях.
>Крупные рекламные группы сосредоточатся...
поживем - увидим. но пока тенденция говорит об обратном.
мы говорим об одном и том же человеке.
Не очень понятно о чем речь. Можно поподробнее?
>странный шаблонизатор
Это Вы о чем? РНР - плохой шаблонизатор? ;)
>отсутсвие абстракций СУБД
PDO?
>единое пространство имен
Использование класссов с методами static - решает эту проблему.
>безумная каша функций без какой либо на то системы
это проблема не языка, а архитектора системы
>медленная работа самого ООП
об этом я уже спрашивал - результаты тестов?
>не использование имеющегося в наличии механизма исключений стандартными функциями
"стандартных" функций в РНР не так много, и (на сколько я помню) они все используют исключения. Что касается расширений (extension), то их не правильно рассматривать как часть РНР. Вот они еще не все переписаны с учетом механизма исключений.
>еще неплохо бы увеличить скорость
эээ... мы о какой скорости сейчас говорим?
Очень хорошее определение :)) Ну раз другого нет, то я буду понимать под перегрузкой возможность в зависимости от количества и типов переменных вызывать тот или иной метод (поскольку часто перегрузкой называют то, что происходит при полиморфизме).
В таком рассмотрении перегрузка:
- есть зло, поскольку нифига не упрощает работу по поддержке кода;
- не является одним из необходимых условий для того чтобы считать язык ОО.
>Без перегрузки конструктора не обойтись в случае создания объекта с использованием каких либо входных переменных.
1. РНР слаботипизованный язык, в этом есть свои плюсы и свои минусы. Но такая особенность дает больше гибкости в написании веб-приложений. Поэтому перегрузка методов в зависимости от принимаемых типов - вообще говоря противоречит идеалогии языка.
2. Много кода - это один вызов func_get_args()?
3. Что-то мне подсказывает, что если для конструктора потребовалось передавать переменное количество параметров, то это косяки в проектировании объектной структуры программы.
>К тому же ООП в PHP не сильно быстрое.
О как. Можно результаты тестов увидеть? По моим данным, возможные задержки при ОО подходе в РНР много меньше тех, что вносят кривые руки программистов. А если все же возникает необходимость в этой экономии на спичках, то значит помочь тут может только чистый С(++), но уж никак не Ruby и не Java.
и еще вопрос - куда деньги нести? ;)
тогда и стоить он будет больше чем 25$ $)
это не правильные пчелы, и они делают не правильный мед :) все зависит от человека-разработчика, от отношения к нему. если он не смог произвести впечатления и внушить доверия, то никакие договора не помогут.
>они просто бросали не закончив
собственно теже проблемы - человеческие отношения. а договор как раз и призван упорядочить отношения в критических ситуациях.
>Крупные рекламные группы сосредоточатся...
поживем - увидим. но пока тенденция говорит об обратном.