develooper Front page | perl.perl5.porters | Postings from May 2013

Re: Proposal: initial type annotation in SV

Thread Previous | Thread Next
May 6, 2013 11:29
Re: Proposal: initial type annotation in SV
Message ID:
On 6 May 2013 13:10, Dave Mitchell <> wrote:
> On Mon, May 06, 2013 at 12:45:14PM +0200, demerphq wrote:
>> On 6 May 2013 12:32, Dave Mitchell <> wrote:
>> > Yes, but my point is that serialization modules will often not do what the
>> > user really intended, and using the canonical type doesn't fix that: it
>> > just shuffles around the cases when it does and doesn't DWIM.
>> >
>> > I think if it's important that something gets serialised in a particular
>> > format, then in some way the programmer needs to tell the serialiser what
>> > that format should be.
>> This suggestion goes completely against Perl hair. Perl is a
>> structless, schemaless language, so how would you even specify such a
>> thing? It would completely prevent people from saying "serialize this
>> structure" without knowing in advance exactly what the structure
>> looked like. I am actually a little surprised you even make the
>> suggestion.
> Then I'm not explaining myself properly.
> The example the OP gave was of serialising data into JSON, then something
> like Javascript reading that json file in and falling over because it was
> expecting a number rather than a string (or whatever).
> Lets make a more concrete example:
> An organisation has some Javascript code that expects to read in a JSON
> file containing lots of (x,y) coordinate pairs. These pairs must be
> floats, not strings. The company also has a bunch of data in a legacy
> format: a plain text file, containing pairs of floats, e.g.
>     0.1234 1.234
>     2.345 3.4566
>     ...
> As a perl programmer, you're given the task of converting those text files
> into json files that the Javascript code can read in. There is no way that
> perl or the serialization module can guess that you want floats rather
> than strings. If you do a naive
>     while (<>) {
>         ($x,$y) = split...;
>         serialise $x, $y;
>     }
> then the chances are that you'll serialise the as strings. Making perl
> record the initial data type isn't going to help here.

Ah yes, I see what you mean now.

> For this scenario, there would have to be some reliable method for the
> programmer to force the serialiser to use floats; there are many
> posibilites, depending on circumstances. For example:
>     * the serialiser documentation could state that for things to be saved
>       as floats, you must do *= 1.0 shortly before saving;
>     * the serialiser could have a global setting saving whether it
>       preferred int or float or string when more than one was valid;
>     * the serialiser could have some sort of format specifier;
>     * etc.
> This is not of course to preclude the possibility of making serialisers
> "better behaved" in the absence of explicit programmer request, e.g. by
> recording the initial state, or by doing more clever things with the
> public/private flags.

Agreed. Thanks for taking the time to explain what you meant.


perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About