[Yaml-core] Towards a Phlisophy Document

[Andrew K. <ku...@sf...>]

> |  = me = Andrew
>    = CCE
--------------

> | Now, let's take the case that's concerning us at the
> | moment, the pointer to int.  Suppose, particularly
> | that I'm trying to dump a C array
> | 
> | int * arr[100];
> | 
> | Without sketching too much of the context, you can see
> | that I wouldn't have declared them pointers unless I
> | needed them, since I could as easily have declared
> | 
> | int arr[100];
> | 
> | So, take it that I need this.  What do I do?
> 
> Two approaches:  (a) let the user provide their
> own "dump" layer which calls the emitter directly,
> this would probably be the approach for a "C" 
> structure; and (b) let the automatic dumper
> (which doesn't exist for "C") use the !ptr type.
> 
> int val[3] = { 8,33,22}
> int *arr[3] = { &val[0], &val[1], &val[2] }
> 
> The arr could be written (there arn't any 
> anchors or references in this case):
> 
> ---
>  - !ptr 
>   =: 8
>  - !ptr
>   =: 33
>  - !ptr
>   =: 22
> 
> | We agree that we don't want to clutter up the YAML with
> | a lot of anchors, but we simply can't pre-judge whether
> | a given pointer is wasted.
> | 

!!  But this is exactly what I'm trying to avoid.

I want it to look like
(Ex A):

- 8
- 33
- 22

because all that extra syntax merely confuses the eye.
As you say, the user must provide his own dump layer
to get this for C, since type is dynamically invisible.

> 
> In "C" goal #3 is not attainable and a "C" programmer
> must use the emitter directly.  However, with a language
> that supports reflection, it could be detected that the
                ^^^^^^^^^^
Is this the same as 'dynamic type detection'?
(like 'ref' operator in Perl)

> items above are pointers, and thus an automated dump
> strategy could be developed.   So, to be consistent with
> goal #3, the !ptr mechanism would be used since an automated
> dumper is possible without requiring user intervention.
> And further, #4 is supported since !ptr is documented in
> the specification and may be recognizable by other languages.
> 
Yes and no.  It isn't good enough merely to document that
such-and-such a thing is a pointer unless you can also
tell whether it's *different* from another pointer which
just happens to point to the same value.  Otherwise the
structure is lost.

If you're going to throw away the structure anyway, I'd
say don't bother to mention that there's a pointer there.
It doesn't do the receiver any good.

In which case you come back to Ex A anyway.

> 
> The type-declaration clutter reduction is probably best
> done with the ^ "cut&paste" operator.  I think being more
> general (with each leaf properly tagged) is a more 
> straight-forward option.
> 

Yes, it is more straightforward.  But, it's less readable
(and if structure info is lost, less usable) than Ex A
above.  Since #2 is more important than #3 or #4 (which
presumably is where ease of implementation comes from)
#2 wins.

See?

Now we have something substantial to refer back to the
philosophy.  If you win this argument, it means changing
the stated philosophy to account for it.

-------

Just a quick question:
> is the default... with single, double, and simple used when
> possible to fit within 76 columns.

I thought the standard width was either 72 or 80.  Where
does 76 come from?

Andrew