Мне кажется лучше пусть разработчик компонента 1 раз позаботиться об уникальности названия своего детища(гугл в помощь), чем пользователи этого компонента потом будут каждый раз в неймспесах его ник прописывать, а потом ещё париться с автозаменой неймспейса, если решат переключиться на альтернативный форк от другого разработчика.
Вы путаете название компонента и название вендора. Vendor — поставщик, т.е. название автора. В случае с Symfony название вендора должно было быть SensioLabs т.к. по сути это их продукт, однако где вы видели в исходниках Symfony namespace SensioLabs? В нормальной практике никто так не делает, это крайне неудобно.
У Зенда название продукта совпадает с названием бренда, тут без вариантов)) А SensioLabs просто нормального названия продукту не придумали, вот и решили вставить себя в корень, заодно и попиариться. Вы посмотрите сотни прочих более ли менее современных библиотек, так больше никто особо не делает.
А что если библиотеку форкать будут, всем потом название корневого неймспейса вручную менять?) А так есть базовая версия Dater, она же на packagist.org под dater/dater опубликована. Кто будет форкать — пусть публикует под myname/dater, но имхо конечные пользователи не должны париться каждый раз namespace у себя перепрописывать только из-за того, что переключились на использование Dater, который был форкнут и доработан другим автором.
Под Vendor name в данном случае понимается название библиотеки, а не класса :) fabpot ведь не пихал свой фреймворк Silex в namespace /Fabpot/Silex github.com/fabpot/Silex, да и вообще так никто не делает. Всегда используют название библиотеки как корневой namespace.
Честно говоря ниразу не видел код, в которым бы в качестве базового namespace имя автора использовалось. Искал на гитхабе примеры организации именований неймспейсов в более ли менее солидных библиотеках, так вот нашёл единственный случай именования по аналогии с Dater/Dater — github.com/ircmaxell/PHP-PasswordLib/blob/master/lib/PasswordLib/PasswordLib.php больше такого нигде не видел.
На самом деле под разными ОС локаль прописывается в разном формате: ru_RU, RUS_RUS, Russian_Russia — 3 разных варианта. В общем я зарефакторил всё на работу в двухсимпольном формате, без привязки к регистру, и без подчёркивания. Теперь работает как-то так $dater->getLocaleByCode('en', 'uk'); второй аргумент опционален.
Это то понятно)) Но неймспейс у библиотеки должен быть не Liaren, а Dater. Отсюда возникает вопрос: как назвать основной класс? А то ведь new \Dater\Dater правда странно смотреться будет. А вот переименовать его в какой-нить Formatter и т.п. рука не поднимается
У меня вот жёсткая дилемма по этому поводу: если переходить на неймспейсы, то придётся переименовывать Dater в \Dater\Dater. Вы считаете нормальным такие именования?
Ваша проблема с потерей времени при конвертации msk-utc-msk в этом примере habrahabr.ru/post/173693/#comment_6036409 заключается в том, что вы делаете modify +13 years над utc, а не над msk. Т.е. в вашем случае правильней было бы реализовать modify, который работал бы перед вызовом modify приводил время к нужному поясу. Например:
И используйте его на здоровье там, где вам нужно модифицировать дату с сохранением времени. Всё ведь просто, и не нужно timezone для каждой даты хранить.
Это я знаю, но все классы перечислять не хочу, а под psr-0 пока не зарефакторил. Так или иначе __autoload.php нужен т.к. из общего числа пользователей Composer процентов 3-5 используют.
Вот вам нравится этот стандарт, кому-то другому нравится трёхбуквенный стандарт RUS, ENG. Таки я не хочу вступать в полемику какой стандарт лучше. Каждый из прочих других стандартов элементарным образом приводится к двух-буквенному.
Смещения даты-времени без учёта часового пояса — это уже костыль :) А вот реализация смещения без учёта поправки на часовой пояс — это вполне себе простенькое и прозрачное решение, которое вы по коду, по идее, лишь в нескольких местах будете использовать.
Я ведь не про переопределение говорил, а про вызов Dater_Locale_English::getByCode('ru'). Лично мне не нравится идея выносить в класс сущности фабричный метод её инициализации. Заводить отдельный класс-фабрику для мапинга кодов локалей на классы я специально не стал, хочется оставить библиотеку в лаконичном виде. Dater::$localeCodes поэтому публичным оставил, кому надо — добавят своих классов локалей и впишут их в Dater::$localeCodes.
По поводу предложения ru_RU я комментом к пул реквесту ответил: форматов может быть сотни, преобразуются они элементарно, не вижу смысла заграмождать Dater этимим преобразованиями, кому надо сами преобразуют перед вызовом getLocaleByCode.
Тем не менее спасибо, что проявили участие! :) Для меня это очень важно.
А что если библиотеку форкать будут, всем потом название корневого неймспейса вручную менять?) А так есть базовая версия Dater, она же на packagist.org под dater/dater опубликована. Кто будет форкать — пусть публикует под myname/dater, но имхо конечные пользователи не должны париться каждый раз namespace у себя перепрописывать только из-за того, что переключились на использование Dater, который был форкнут и доработан другим автором.
И используйте его на здоровье там, где вам нужно модифицировать дату с сохранением времени. Всё ведь просто, и не нужно timezone для каждой даты хранить.
По поводу предложения ru_RU я комментом к пул реквесту ответил: форматов может быть сотни, преобразуются они элементарно, не вижу смысла заграмождать Dater этимим преобразованиями, кому надо сами преобразуют перед вызовом getLocaleByCode.
Тем не менее спасибо, что проявили участие! :) Для меня это очень важно.