Re: Next YAML: drop equality definition

On 3/6/16, Oren Ben-Kiki <[email protected]> wrote:
> On Sun, Mar 6, 2016 at 7:00 PM, Osamu TAKEUCHI <[email protected]> wrote:
>> If the layered structure of the YAML processor
>> do not allow it, the layered structure itself
>> should be revised. I don't see how the layered
>> structure is related to the current topic,
>> though.
>
> It is crucial to the discussion. We all agree that key duplication
> detection _must_ be done at the application layer, but the point is that a
> _limited_ form of key duplication detection _may_ and _should_ be done,
> especially in YAML processors that do not even _have_ an application layer.

Where the YAML processor (perhaps some streaming processor?), -is- the
application.

> This is because, as you put it, "it makes the serialized documents much
> more readable or portable".

I guess I don't understand Osamu's "it makes the serialized documents
much more readable or portable". As long as the spec does not limit a
streaming processor from either flag an error or not flag, depending
on what the application (user) wants, that's fine AFAICT.

>> Similarly, I do not want to forbid PHP users
>> to store a PHP's native key-order-aware hash
>> into a key-order-unaware YAML mapping
>
> The problem is, how can you tell whether this is/not safe to do? When
> dumping such a hash table to YAML, the application needs to provide some
> hint to the YAML processor whether this is actually safe. By default, it is
> _not_ safe, so without an explicit hint, the YAML processor _should_ do the
> safe thing and emit it as an !!omap.

ACK!

I imagine the problem would arise if an application requires key
ordering, uses one library for saving, then loads with a library that
does not preserve key ordering. Or two applications, and one saves
without specifying that key order is required, where it is a different
application doing the loading.

...
> Really? People would be very surprised to hear that { a: 1, a: 2 } is
> actually OK because some application somewhere _may_ decide it wants scalar
> string keys to use "identity-based equality".
>
> So *No*.

Ack.

> So we _can_ complain about them being equal at an earlier processing stage.
> We do not _require_ a YAML processor to do so, but we _allow_ and
> _encourage_ it to do so.

Sounds fine. As long as it's not required, a processor can be
configured to complain or not.

------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval