не, а если у тебя где-то по логике должна быть json-строка, но вот так совпала что в ней цифры..
13 октября 2015 г., 22:33 пользователь vividsnow <[email protected]> написал: > On 10/13/2015 10:20 PM, Victor Efimov wrote: >> 13 октября 2015 г., 22:18 пользователь vividsnow <[email protected]> >> написал: >>> On 10/13/2015 07:49 PM, Olga Smirnova wrote: >>>> Ни за ни против типизации, просто пример, когда строгая типизация могла бы >>>> решить проблему простым способом >>>> >>>> Примерно вот такой кусок кода: >>>> >>>> use JSON qw(to_json); >>>> use Data::Dumper; >>>> >>>> my $numbers = { >>>> one => 1.5, >>>> two => 2, >>>> }; >>>> my $str = to_json( $numbers ); >>>> print $str . "\n\n"; >>>> >>>> my $str2 = Dumper($numbers); >>>> my $str3 = to_json( $numbers ); >>>> >>>> print $str3 . "\n\n"; >>>> >>>> Получаем вот такой вывод: >>>> >>>> {"one":1.5,"two":2} >>>> >>>> {"one":"1.5","two":2} >>>> >>>> Т.е. берем структуру с заведомыми чиселками, которую нужно преобразовать в >>>> json, затем применяем к ней какую-нибудь функцию, в данном случае Dumper, >>>> и теперь наша дробная >>>> чиселка легким движением руки превращается в строчечку при >>>> json-сериализации. Если бы была строгая типизация, то такой проблемы бы не >>>> возникло. >>>> >>>> Конкретно у нас это стало проблемой, когда понадобилось посылать внутри >>>> json'а сумму в рублях (соответственно, это дробная чиселка), а на >>>> принимающей стороне был сервис, >>>> написанный на скале (т.е. со строгой типизацей), валидатор которого >>>> ругался на наши "1.5" и говорил, мол это не чиселка. >>>> >>>> Тут, конечно, можно сказать, мол, просто не используйте Dumper (или любую >>>> другую функцию, неявно преобразующую тип), но это не панацея, т.к. в любой >>>> момент в проект может >>>> прийти новый человек, не знающий про эту фичу, который возьмет да и начнет >>>> использовать одну из таких функций перед отправкой и все нахрен поломается. >>>> В нашем случае решением проблемы стал перевод единицы измерения суммы из >>>> рублей в копейки и на нашей стороне и на принимающей (благо, принимающий >>>> сервис тоже наш), т.е. >>>> избавление от дробных чисел - перед отправкой для суммы всегда делался int >>>> и уже неважно было, что делали с этой чиселкой раньше. >>> >>> как вариант в функции-сериализаторе приводить значение к соотв. типу через: >>> >>> to_json({ one => $numbers->{one} +0, two => $numbers->{two} +0 }) >> >> да, если функция сериализации знает какие поля будут числами, а какие - нет > > если нужно обобщенное решение, то можно "пробежаться" по структуре и: > $_+=0 if Scalar::Util::looks_like_number($_) > >> >>> >>> по этой теме на CPAN'е есть: https://metacpan.org/pod/JSON::Schema::Fit >>> >>>> >>>> С другой сторону, в пользу не строгой типизации - если бы такой json (с >>>> "1.5") пришел в сервис, написанный на перле, то проблемы бы не было - мы >>>> бы адекватно распарсили и >>>> 1.5 и "1.5" >>>> >>>> >>>> 13.10.2015 19:08, Victor Efimov пишет: >>>>> твой пример был про программиста, который написал $b='20' с кавычками, а >>>>> потом решил с переменной $b произвести сложение. это не вменяемый >>>>> программист, даже по >>>>> реальностям Perl5. он присваивает переменной заведомо строковое значение >>>>> прямо в исходном коде, зачем-то пишет кавычки, а затем эту же переменную >>>>> пытается складывать. >>>>> если у тебя какой-то xml парсер - то и приводи примеры xml парсера. я за >>>>> то чтобы избавиться от абстракций в этом треде, тут и так полно >>>>> недопонимания. так что лучше >>>>> пример кода обсужать а не на пальцах пытаться что-то объяснить и >>>>> демагогией заниматься. >>>> >>>> -- >>>> С уважением, >>>> >>>> Ольга Смирнова >>>> Perl-программист проекта Деньги@mail.ru >>>> раб.: +7 (495)-725-63-57 (внутр. 2199) >>>> моб.: +7 (926)-959-16-23 >>>> e-mail: [email protected] <mailto:[email protected]> >>>> skype: olga_smirnova89 >>>> mail-agent: [email protected] >>>> ISQ: 232733122 >>>> >>>> mail.ru <http://mail.ru> >>>> >>>> >>> -- >>> Moscow.pm mailing list >>> [email protected] | http://moscow.pm.org > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
