Front page | perl.perl5.porters |
Postings from May 2013
Re: Proposal: initial type annotation in SV
Thread Previous
|
Thread Next
From:
demerphq
Date:
May 6, 2013 11:29
Subject:
Re: Proposal: initial type annotation in SV
Message ID:
CANgJU+UVOUX-g+UmH4mqY85hJqsaknJ-d+DdrqU5gGVTXeAu4Q@mail.gmail.com
On 6 May 2013 13:10, Dave Mitchell <davem@iabyn.com> wrote:
> On Mon, May 06, 2013 at 12:45:14PM +0200, demerphq wrote:
>> On 6 May 2013 12:32, Dave Mitchell <davem@iabyn.com> 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.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous
|
Thread Next