Да, без нормальных Exception жизнь не мила....Автор оригинала: [sid]
Хотя чувствуется, что не хватает возможностей пятерки
Мы подумываем о том, чтобы чуть позже(скажем с выходом 5.1) перейти на пятерку, но таким образом, чтобы изменения были минимальными, т.е как раз добавятся только полноценные Exception(лопатить весь код совершенно нет желания...)А это что означает?
Разве они пока не в полном виде?Это точно. Мы пока никак не можем решить насчет механизма обработки ошибок. Этот вопрос не будет решен в и alpha2. А на пятерку переход пока не скоро намечен. Есть предложения?Хотя чувствуется, что не хватает возможностей пятерки
![[sid]](https://secure.gravatar.com/avatar/c51853b199f011af6ff7bfdc5973af53?s=96){kind=avatar}
Да вот Handle::Resolve() напрягает!Автор оригинала: pachanga
Да, без нормальных Exception жизнь не мила....
А это что означает?
А как бы хотелось? Чтобы прокси объект автоматически подменял свою реализацию при первом обращении к любому из методов? Насколько я знаю, даже под PHP5 так сделать не удастся....
Ну вообще-то там есть некоторая логика в организации этого нагромождения классовАвтор оригинала: fixxxer
о, неужели кто-то, кроме авторов сабжа, смог разобраться в этом нагромождении классов?
К тому же постепенно растущая документация(и тесты!) должна быть неплохим подспорьем, как правильно уже заметили, было бы желание.....
Почему?? Можно использовать ObjectOverload!!!
. Вроде бы в ZE2 ничего революционного, а как нехватает этих самых эволюционных изменений. А использовать в широком масштабе их не получиться, по крайней мере в ближайшее время!!! (Извините за оффтопик)!
Мне всегда казалось, что CMF нужны для упрощения разработки, а не наоборот.
Ну и складывается впечатление, что авторы слишком много читали про Design Patterns, какое-то прямо религиозное поклонение. Не спорю, концепция замечательная, но это же не догма. Прямо как MVC Hello World поулчается
Абсолютно правильное замечание насчет 4-ки, покопавшись немного с __call, мы просто забили на эту затею. Однако, с 5-кой не возились поэтому спасибо за информацию.
На самом деле правильно сделали, т.к здесь ведутся уже крайне околонаучные дебаты. Самое главное, что стрелочка moved естьАвтор оригинала: syfisher
Млин, нас опять в "корзину" переместили
Не мог бы ты ради примера привести CMF, которая бы имела небольшое время на освоение(learning curve) и при этом позволяла бы себя подстраивать практически под любые нужды?Автор оригинала: fixxxer
Мне всегда казалось, что CMF нужны для упрощения разработки, а не наоборот.
Я могу сказать только одно, что самое ценное(по-крайней мере для нас) в PHP5 из того, что появилось - exceptions. Все остальное прекрасно делается и на PHP4(с определенными оговорками и "грязными" решениями, конечно). А если учитывать, сколько времени займет переход хостеров на пятерку, то преимущество пятерки меркнетВообще, сама идея реализовывать что-то подобное на 4-ке - хмм...странная
И не только Design Patterns
А также: XP, TDD, Domain Driven Design и проч. И из просто религиозного поклонения это уже превратилось в фанатизм и болезнь, причем заразную.Естественно не догма, у разработчика всегда есть выбор. Просто для нас LIMB - некоторое выражение всего нашего эволюционного опыта разработки. И если кто-то находит это полезным, мы только рады.Не спорю, концепция замечательная, но это же не догма. Прямо как MVC Hello World поулчается
Честно говоря, почти уверен в невозможности таковой.
Вот видишь....Автор оригинала: fixxxer
Честно говоря, почти уверен в невозможности таковой.
Пойми меня правильно, я обоими руками за PHP5, только вот клиенту не объяснишь, что на его любимом хостинге проект ну никак не "заведется" еще неизвестное количество времени из-за нежелания администратора поставить пятерку.
Еще раз прочитай мой пост. Я не говорю, что нельзя. Я говорю, что через задницу.
Тот же AbstractFactory, например - все приходящие мне в голову решения на 4-ке никак не назвать элегантными.
Кроме интерфейсов? Рефлексия, итераторы, нормальная перегрузка методов и свойств, авт. проверка аргументов методов и функций на соответсвтие обекта определенному типу класса... практически уверен, что список можно продолжить
