вопрос такой: а не из PEAR ли там некоторое количество кода в limb/core/lib?
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
о PEAR [from=Limb CMS]
- Автор темы Sad Spirit
- Дата начала
pachanga
Новичок
Да есть и из PEAR, однако этот код жестко проверен и отрефакторен: проблема с PEAR в том, что просто его взять и использовать рука не поднималась 
Там порой такие ляпы(тот же PEAR.php - это же жуть!), с другой стороны изобретать колесо для отправки, скажем, почты тоже нецелесообразно - мы так и не пришли к единогласному решению по поводу использования внешних библиотек
Да и потом нам очень не нравятся заморочки с inlude_path: по-хорошему, продукт должен устанавливаться простой установкой констант, типа, PEAR_DIR - почему так не сделано, ума не приложу...
Вообще это такая больная тема...
Нет на PHP стандартных решений не избыточных по коду и не представляющих из себя кухонный комбайн. Каждый норовит использовать свои coding conventions и т.п...
Но это проблема времени.
Вот и с WACT тоже есть заморочки - мы переделали под себя почти весь их движок, тоже ничего хорошего в этом нет. Сейчас ведутся предварительные разговоры с WACT разработчиками о том, как можно было бы использовать в LIMB WACT полностью как внешний продукт.
С появлением PHP 5, хотя бы отпадет проблема с частными обработчиками ошибок, в одном месте PEAR::is_error(), в другом - Propel::is_exception()....
Именно с пятой версией мы надеемся использовать внешние библиотеки по-нормальному, без переделки существующего кода, т.к. это очень дорогое удовольствие
Единственная огромная ложка дегтя в бочке меда PHP 5 - отсутствие namespace'ов. Кому-то это всего лишь syntax sugar, но я с этим не согласен. Я слышал, что в python же есть решение этой проблемы...
-~{}~ 02.06.04 00:46:
В продолжении темы повторного использования кода:
http://www.sitepoint.com/forums/showthread.php?t=169072
Там порой такие ляпы(тот же PEAR.php - это же жуть!), с другой стороны изобретать колесо для отправки, скажем, почты тоже нецелесообразно - мы так и не пришли к единогласному решению по поводу использования внешних библиотек
Да и потом нам очень не нравятся заморочки с inlude_path: по-хорошему, продукт должен устанавливаться простой установкой констант, типа, PEAR_DIR - почему так не сделано, ума не приложу...
Вообще это такая больная тема...
Нет на PHP стандартных решений не избыточных по коду и не представляющих из себя кухонный комбайн. Каждый норовит использовать свои coding conventions и т.п...
Но это проблема времени.
Вот и с WACT тоже есть заморочки - мы переделали под себя почти весь их движок, тоже ничего хорошего в этом нет. Сейчас ведутся предварительные разговоры с WACT разработчиками о том, как можно было бы использовать в LIMB WACT полностью как внешний продукт.
С появлением PHP 5, хотя бы отпадет проблема с частными обработчиками ошибок, в одном месте PEAR::is_error(), в другом - Propel::is_exception()....
Именно с пятой версией мы надеемся использовать внешние библиотеки по-нормальному, без переделки существующего кода, т.к. это очень дорогое удовольствие
Единственная огромная ложка дегтя в бочке меда PHP 5 - отсутствие namespace'ов. Кому-то это всего лишь syntax sugar, но я с этим не согласен. Я слышал, что в python же есть решение этой проблемы...
-~{}~ 02.06.04 00:46:
В продолжении темы повторного использования кода:
http://www.sitepoint.com/forums/showthread.php?t=169072
pachanga
Новичок
То что будет ниже, это очень IMHO 
Так в чем же проблема написать:
include_once(PEAR_DIR . '/DB.php'); (сразу понятно к какому продукту относится данный include)
вместо
include_once('DB.php'); ?
Это же дает ряд преимуществ, по крайней мере не надо возиться с include_path(порой это сделать не так-то просто, даже ini_set мне видится грубым решением) и называть свои модули отличным способом.
Да и сам по себе include происходит быстрее...
Кстати, еще такая вещь: в PEAR классы раскиданы по модулям, опять же IMHO не самое удачное решение, читабельность страдет. Сами PEAR разработчики недавно поднимали вопрос об изменении структуры хранения классов, a la "один класс - один файл".
Возможно, в PEAR2 именно так и поступят.
Вообще это проблема, связанная с application consistency. Проще говоря, приложение должно быть не просто собрано кое-как из различных составляющих, но представлять из себя нечто цельное и законченное.
Так вот, на данный момент сделать приложение цельным, используя несколько внешних PHP библиотек, очень трудно
Нет единообразия и принятых стандартов среди разработчиков, всякий раз придумывая колесо, я....опять же придумываю колесо, т.к. на чужом квадратном колесе далеко не уедешь
Так в чем же проблема написать:
include_once(PEAR_DIR . '/DB.php'); (сразу понятно к какому продукту относится данный include)
вместо
include_once('DB.php'); ?
Это же дает ряд преимуществ, по крайней мере не надо возиться с include_path(порой это сделать не так-то просто, даже ini_set мне видится грубым решением) и называть свои модули отличным способом.
Да и сам по себе include происходит быстрее...
Кстати, еще такая вещь: в PEAR классы раскиданы по модулям, опять же IMHO не самое удачное решение, читабельность страдет. Сами PEAR разработчики недавно поднимали вопрос об изменении структуры хранения классов, a la "один класс - один файл".
Возможно, в PEAR2 именно так и поступят.
Вообще это проблема, связанная с application consistency. Проще говоря, приложение должно быть не просто собрано кое-как из различных составляющих, но представлять из себя нечто цельное и законченное.
Так вот, на данный момент сделать приложение цельным, используя несколько внешних PHP библиотек, очень трудно
Нет единообразия и принятых стандартов среди разработчиков, всякий раз придумывая колесо, я....опять же придумываю колесо, т.к. на чужом квадратном колесе далеко не уедешь
Претензия первая, квази-юридическая: там везде написан ваш копирайт и лицензия LGPL, без всяких указаний на авторов и исходную лицензию. Насколько я понимаю, перелицензировать с BSD/PHP на LGPL вы право имеете, но вот не указывать исходных авторов...Автор оригинала: pacha
Да есть и из PEAR, однако этот код жестко проверен и отрефакторен: проблема с PEAR в том, что просто его взять и использовать рука не поднималась
Там порой такие ляпы(тот же PEAR.php - это же жуть!), с другой стороны изобретать колесо для отправки, скажем, почты тоже нецелесообразно - мы так и не пришли к единогласному решению по поводу использования внешних библиотек
...
Вот и с WACT тоже есть заморочки - мы переделали под себя почти весь их движок, тоже ничего хорошего в этом нет. Сейчас ведутся предварительные разговоры с WACT разработчиками о том, как можно было бы использовать в LIMB WACT полностью как внешний продукт.
Претензия вторая, идеологическая: если вы используете Open Source решения и в них вам что-то не нравится, то гораздо лучше отправлять предложения/патчи разработчикам. Я тоже до этого долго доходил, прошёл через "рефакторинг" и включение чужого кода в свои проекты. Вот и вы щас будете повторно проделывать работу, вместо того, чтобы сразу объединиться с разрабтчиками WACT.
Претензия третья, отдельная, PEARовская: если вы критикуете PEAR за их PEAR.php, то должны принимать во внимание, что именно разработчики PEAR проталкивали новые фичи --- которые в оном файле эмулируются --- в PHP5. Так что PEAR.php --- памятник не убожеству PEAR, а убожеству PHP4.
pachanga
Новичок
По поводу первой претензии - согласен, будет исправлено, кстати, спасибо. Никого не хотели обидеть.
По поводу второй - именно поэтому мы сейчас пытаемся сотрудничать с WACT разработчиками, по крайней мере, с их стороны есть интерес. "Отправлять предложения/патчи" - полностью согласен, но когда "горит" коммерческий проект, никуда не денешься, вначале все сам исправишь и только через определенное время пошлешь патч разработчикам, не так ли?
По поводу третьей - моя критика PEAR абсолютно субъективная(как я и сказал), кого-то все устраивает. Однако всем очевидно, что с этим что-то надо делать. И, насколько я знаю, дела с PEAR начинают улучшаться....
Кстати, появилась тенденция в PEAR пакетах полностью отказываться от PEAR.php.
-~{}~ 02.06.04 14:39:
Ссылка в тему: http://php.weblogs.com/2004/06/01#a3528
По поводу второй - именно поэтому мы сейчас пытаемся сотрудничать с WACT разработчиками, по крайней мере, с их стороны есть интерес. "Отправлять предложения/патчи" - полностью согласен, но когда "горит" коммерческий проект, никуда не денешься, вначале все сам исправишь и только через определенное время пошлешь патч разработчикам, не так ли?
По поводу третьей - моя критика PEAR абсолютно субъективная(как я и сказал), кого-то все устраивает. Однако всем очевидно, что с этим что-то надо делать. И, насколько я знаю, дела с PEAR начинают улучшаться....
Кстати, появилась тенденция в PEAR пакетах полностью отказываться от PEAR.php.
-~{}~ 02.06.04 14:39:
Ссылка в тему: http://php.weblogs.com/2004/06/01#a3528
нет конечно.
я просто хотел обратить внимание, что переписывание чужих классов под свои стандарты кодирования и т.п. --- напрасная трата времени и сил (особенно когда разработчик исходного класса что-нибудь в него добавит/поправит).
можно было бы обойтись написанием wrapper'а на PEAR_Error и наступить на горло собственной песне в плане include_path (тебя же не напрягает, что в ОС есть PATH, хотя можно было бы и писать каждый раз полный путь к файлу).
претензии к тому, что класс PEAR "тяжёлый", не лишены, хм, оснований. но и вся ваша CMS тоже не совсем образец лёгкости, без bytecode cache вряд ли весело использовать.
pachanga
Новичок
После долгой "религиозной войны" мы тоже к этому пришли
Быть может так и поступим, но...пока подождем, пока все устаканится в стане PEAR и PHP(выход 5 версии, где каждый RC не совместим с предыдущим, тоже еще та головная боль).
Кстати, еще один довод не в пользу include_path - как сделать релиз, который содержит сразу в себе все необходимые компоненты? Ведь придется устанавливать пятое-десятое, не очень приятная процедура с точки зрения конечного пользователя...
Или я ошибаюсь?Спору нет, наша CMS пока далека от рекордных показателей по скорости. Видит Богпретензии к тому, что класс PEAR "тяжёлый", не лишены, хм, оснований. но и вся ваша CMS тоже не совсем образец лёгкости, без bytecode cache вряд ли весело использовать.
- мы всеми силами стараемся сделать код чище и понятнее, без лишних извратов. Поэтому все библиотеки внешние пропускали "через себя". Но так дальше, естесно, продолжаться не может...во что это выльется? Поживем - увидим...
Кстати, очень интересная ссылка по поводу оптимизации, которую нам также стоит применить:
http://www.sitepoint.com/blog-post-view.php?id=167792
... и более детально:
http://wact.sourceforge.net/index.php/ResolveHandle