Допускаются ли пакеты/классы с похожей функциональностью?
Никаких проблем с конкурирующими пакетами не возникает, однако мы бы хотели избежать появления 10-ти классов шаблонов, 7-ми различных классов по работе с почтой и 3-х врапперов для баз данных, которые будут выполнять одни и те же действия, отличаясь только именами функций.
Для начала, задайте себе вопрос: "Почему я хочу добавить новый пакет?". Самые плохие варианты ответа это: "Хочу увидеть мое имя в списке участников PEAR" и "Я не понимаю API уже существующего пакета".
Обычно, причиной добавления нового пакета является отсутствие функциональности, особенности поведения или проблемы со скоростью/эффективностью у существующего пакета. В этом случае, вы должны удостовериться в том, что расширить или улучшить этот класс/пакет невозможно. Если это действительно так, то вам действительно следует добавить новый пакет. "Действительно невозможно" означает, что нет никакой возможности добавить новую функциональность без изменения основ класса/пакета.
Если вы все-таки решили создать новый класс - старайтесь поддерживать совместимость API со старыми классами настолько, насколько это возможно. Если это невозможно в принципе - попробуйте сделать враппер для поддержания совместимости. И неважно, что этот враппер может требовать значительных ресурсов - так или иначе, но он значительно упростит процесс миграции.
Добавление конкурирующего класса обязательно должно быть согласовано в листе разработчиков PEAR!
| Пред. | Начало | След. |
| Должен ли я прилагать примеры и/или тестовые файлы к моему пакету и где они должны храниться? | Уровень выше | У меня есть вопрос, который касается PEAR. Где я могу его задать? |