Уважаемый, Вы совсем потеряли восприятие размеров?)) PHPUnit на одной функции? Отдельный файл с проверками? :)
Это демонстрация, а не тесты, если уж совсем быть точным.
Я понимаю, что существуют «паттерны правильного программирования», но не надо бить по мухе и пушки ;-)
Нет, не так. +7 и (8) вместе — это уже ошибкой пахнет :)
Из обсуждений выше видно, что в скобках указывается то, что набирать необязательно.
Другими словами, для москвичей (если бы остался 095, а не два кода, будь они неладны), указывалось бы 123-45-67 при локальном номере, 8 812 123-45-67, при междугороднем, а т.к. мы часто не знаем, откуда читатель номера, то пишем 8 (812) 123-45-67, намекая на то, что 812 набирать надо только в случае, если номер нелокален.
Напротив дело обстоит с мобильными операторами. Получается, что писать 8(926)123-45-67 в корне неправильно, т.к. без 926 номер набирать нельзя.
Я обязательно покопаюсь подробно в этой теме и выкачу новый топик вместе с реализованными находками в обновленном коде функции, преобразовав ее в полноценный класс.
Судя по данным с www.hella.ru/code/codeuro.htm, это именно код пятизначный, т.е. в одном случае (4152), а в другом — (41522). А вот с т.з. маршрутизации на АТС-ках, Вы правы, им достаточно тупо проверить пятую цифру кода и направить ее либо в область, либо в город.
Обсуждалось выше уже, но не могли бы Вы уточнить, код города всегда указывается вне скобок в этом случае?
Т.е. если я живу в городе 870, я все равно должен набирать 870-…, а если в другом, то 0-870-…?
1. добавить информацию для каждой страны касательно формата разбиения групп цифр
2. добавить флаг в функцию, который бы позволял указывать страну в виде международного кода, относительно которой необходимо форматировать
3. добавить возможность самостоятельно указать паттерн форматирования
А чего минусуем?
1. промежуточные запросы по кускам недописанных слов — это явно не то, что я ищу
2. единственное, чего я из информации увижу больше — таргетинговой рекламы
3. вейв действительно оказался сырым и неполноценным для преследуемых целей
Проблема не встает — просто приводи их в единый формат при записи в БД, а окошко с телефонным номером дели на три части для того, чтобы было очевидно, что нужно ввести не только локальный номер, но и указать код города и страны.
Имеет смысл сделать дерево с несколькими вершинами, чтобы использовать его не только по прямому назначению, но и для форматирования номеров, где код города присутствует, а страна — нет.
Это демонстрация, а не тесты, если уж совсем быть точным.
Я понимаю, что существуют «паттерны правильного программирования», но не надо бить по мухе и пушки ;-)
Из обсуждений выше видно, что в скобках указывается то, что набирать необязательно.
Другими словами, для москвичей (если бы остался 095, а не два кода, будь они неладны), указывалось бы 123-45-67 при локальном номере, 8 812 123-45-67, при междугороднем, а т.к. мы часто не знаем, откуда читатель номера, то пишем 8 (812) 123-45-67, намекая на то, что 812 набирать надо только в случае, если номер нелокален.
Напротив дело обстоит с мобильными операторами. Получается, что писать 8(926)123-45-67 в корне неправильно, т.к. без 926 номер набирать нельзя.
Я обязательно покопаюсь подробно в этой теме и выкачу новый топик вместе с реализованными находками в обновленном коде функции, преобразовав ее в полноценный класс.
Т.е. если я живу в городе 870, я все равно должен набирать 870-…, а если в другом, то 0-870-…?
Или я отстал от жизни и телефонные номера теперь указывают в UTF?
2. добавить флаг в функцию, который бы позволял указывать страну в виде международного кода, относительно которой необходимо форматировать
3. добавить возможность самостоятельно указать паттерн форматирования
Добавлю паттерн форматирования к информации о стране в базу и обновлю код.
Спасибо.
481-61-45 — Вы ведь это имеете в виду?
1. промежуточные запросы по кускам недописанных слов — это явно не то, что я ищу
2. единственное, чего я из информации увижу больше — таргетинговой рекламы
3. вейв действительно оказался сырым и неполноценным для преследуемых целей