an0nymВ моём случае переспрашивать юзера не надо.
как это ненадо? если ваша функция не может переварить какойлибо формат, то явно придется спросить еще раз? а может и не раз

an0nymЭто легко исправляется.

а когда исправится тогда возможно и другие баги всплывут)
чем сложнее реализация тем больше в ней ошибок

an0nymЛучше приведите контр-пример, когда мой метод откровенную чушь пропустит - вот тут я как раз в себе не уверен и жду критики. Самому интересно.
понимаете, мы с вами по разному подошли к решению. вы пытаетесь склонить юзера к принятому у вас формату, если юзер нехочет(или непонимает) что нужно ввести - то все тупик - функция ваша просто ничего не пропустит.

я же пошел по пути другому. мы ждем от юзера сумму - вот пусть ее и вводит, с ЛЮБЫМИ разделителями. он может даже не сам ее набирать а скопировать с ДРУГИХ ИСТОЧНИКОВ (с другого сайта, программы и т.д.). , а там может попасться любой мусор. и моя функция нормализует то что он ввел. может комуто пригодится.
по такому принципу я писал парсер для даты, при импорте данных с других систем в мою. формат везде отличался то dd/mm/yyyy то yy.mm.dd то еще как. заставить я никого не мог, формат мог меняться без предупреждения меня. и приходилось ЕСТЬ все эти форматы. а чтоб не парится с каждым я сделал подобную функцию. которая сама определяла в каком формате дата и нормализовывала ее в нужный мне. валилась она только когда ну уж совсем никак нельзя было интерпретировать корректно дату.

если будут мысли по вашей функции еще - скажу. пока мыслей нет

an0nym,

кстати вот:
var_dump(parse_number('1234')); // NULL

Edd.Dragonr uну и пусть)
Вот было бы забавно, если б так думали разработчики онлайн-банкингов. Вводишь по-своему, оно парсит по-своему - финансовые операции, чо!
в случаях связанных с фин.операциями все равно всегда спрашивают подтверждения, показывая при этом все реквизиты платежа и сумму. так что все в рамках концепции)