pali

Hi! Another way to ensure of generating correct json according to some type specification is to extend encode_json function to process second parameter which get type specification. And JSON::PP itself...

It is for more complicated code... E.g. when you get perl structure from another functions or other modules and want to generate correct JSON. Or when you got perl scalar...

@charsbar: Already looked at it and also other cpan modules. JSON::Schema is just for finite/non-recursive structures, but perl structures can be DAG... Anyway, my proposal is backward compatible (adds optional...

Merge request created: https://github.com/makamaka/JSON-PP/pull/32 Move discussion here.

The whole `mysql_enable_utf8` was just experimental and totally broken prior to DBD::mysql 4.042. Experimental status was also written in documentation, see: https://metacpan.org/pod/release/CAPTTOFU/DBD-mysql-4.033/lib/DBD/mysql.pm#mysql_enable_utf8 I'm not sure what we can done here....

So... what do you suggest? As wrote I have no idea what can be done here. Probably the best solution would be to fix broken code. And about `mysql_enable_utf8` usage...

Problem with old `mysql_enable_utf8` implementation is that it behave "pseudo-randomly". For frozen combination of perl at specific version, all cpan modules at specific version and user application it acts deterministic....

@Grinnz is right. And moreover un-upgraded strings are created by default from string constants if you do not `use utf8` in your file from which those strings come from. Also...

> That’s some other module changing its behaviour. I cannot agree here with you, because calling utf8::upgrade() or composing string via `\x{...}\x{...}` sequences, or via `\N{...}` is not behavior change....

> old behavior was widely deployed What we learnt from this is that developers do not read documentation nor care about states like "This option is experimental and may change...