Pull to refresh
55
0
liaren @liaren

User

Send message
А чем обусловлено это ваше «должно»?)
Мне кажется лучше пусть разработчик компонента 1 раз позаботиться об уникальности названия своего детища(гугл в помощь), чем пользователи этого компонента потом будут каждый раз в неймспесах его ник прописывать, а потом ещё париться с автозаменой неймспейса, если решат переключиться на альтернативный форк от другого разработчика.
Вы путаете название компонента и название вендора. Vendor — поставщик, т.е. название автора. В случае с Symfony название вендора должно было быть SensioLabs т.к. по сути это их продукт, однако где вы видели в исходниках Symfony namespace SensioLabs? В нормальной практике никто так не делает, это крайне неудобно.
Это что по вашему Yaml — чей-то ник?)
Это что по вашему Yaml — это чей-то ник?)
У Зенда название продукта совпадает с названием бренда, тут без вариантов)) А 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 приводил время к нужному поясу. Например:

$date = new DateTime('2000-01-01', new DateTimeZone('Europe/Moscow'));
echo $date->format('Y-m-d H:i:sP') . PHP_EOL; // 2000-01-01 00:00:00+03:00
$date->setTimeZone(new DateTimeZone('UTC'));
echo $date->format('Y-m-d H:i:sP') . PHP_EOL; // 1999-12-31 21:00:00+00:00
$date->setTimeZone(new DateTimeZone('Europe/Moscow'));
$date->modify('+ 13 year');
echo $date->format('Y-m-d H:i:sP') . PHP_EOL; // 2013-01-01 00:00:00+04:00


И используйте его на здоровье там, где вам нужно модифицировать дату с сохранением времени. Всё ведь просто, и не нужно timezone для каждой даты хранить.
Composer есть ведь. Устанавливайте «dater/dater» => «dev-master» А psr-o будет как только на неймспейсы зарефакторю.
Про classMap я уже сказал, а file я как раз и использую см. github.com/barbushin/dater/blob/master/composer.json
Это я знаю, но все классы перечислять не хочу, а под psr-0 пока не зарефакторил. Так или иначе __autoload.php нужен т.к. из общего числа пользователей Composer процентов 3-5 используют.
А вот этого я не учёл. Спасибо вам. Скоро зарефакторю на новый стандарт.
Вот вам нравится этот стандарт, кому-то другому нравится трёхбуквенный стандарт RUS, ENG. Таки я не хочу вступать в полемику какой стандарт лучше. Каждый из прочих других стандартов элементарным образом приводится к двух-буквенному.
Смещения даты-времени без учёта часового пояса — это уже костыль :) А вот реализация смещения без учёта поправки на часовой пояс — это вполне себе простенькое и прозрачное решение, которое вы по коду, по идее, лишь в нескольких местах будете использовать.
Я ведь не про переопределение говорил, а про вызов Dater_Locale_English::getByCode('ru'). Лично мне не нравится идея выносить в класс сущности фабричный метод её инициализации. Заводить отдельный класс-фабрику для мапинга кодов локалей на классы я специально не стал, хочется оставить библиотеку в лаконичном виде. Dater::$localeCodes поэтому публичным оставил, кому надо — добавят своих классов локалей и впишут их в Dater::$localeCodes.

По поводу предложения ru_RU я комментом к пул реквесту ответил: форматов может быть сотни, преобразуются они элементарно, не вижу смысла заграмождать Dater этимим преобразованиями, кому надо сами преобразуют перед вызовом getLocaleByCode.

Тем не менее спасибо, что проявили участие! :) Для меня это очень важно.

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity