[YAML] Blank Array without Hash

[patrickheeney]

Right now YAML component dumps an empty array like this: $dump = array('test' => array()); as test: { }. In some applications that use the YAML it needs to be test: [ ] a list instead of a hash.

In the symfony codebase on this line (https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Yaml/Inline.php#L160) I found:

        $keys = array_keys($value);
        if ((1 == count($keys) && '0' == $keys[0])
            || (count($keys) > 1 && array_reduce($keys, function ($v, $w) { return (integer) $v + $w; }, 0) == count($keys) * (count($keys) - 1) / 2)
        ) {

It looks to me if I pass $dump = array('test' => array('0' => '')) It should work? However this code outputs: test: - ''. Its successfully using the list format but its passing the blank value. I think another conditional is missing to be able to create: test: [ ]. I checked the unit tests and I can't find anywhere that explains what (1 == count($keys) && '0' == $keys[0]) was intended for other than this purpose.

EDIT: It doesn't look to be hitting that section of code at all since my indent level is really high. However I am still tring to figure out how to get it to output a [ ] instead of hash { } since it is invalid yaml for what I am using it for and a blank array defaults to the hash.

[jakzal]

I'm afraid there's no good solution for your problem.

How can you tell that an empty array is suppose to be treated as a hash or an array? Furthermore, whatever we do we have to be consistent - so either dump an empty array as [] or {} - this means that one way or another you'll run into this problem.

[patrickheeney]

I disagree on the consistency part since this a new feature request and not a change. I realize there is not a perfect solution for this so I am hoping we can come up with a way to make it work. I think the default empty array should be a hash {} as it is now. What I am looking for is setting or perhaps passing a certain type of array to force it to be an empty list [].

So I think if you want an empty hash then pass an empty array or if you want an empty list pass something in. Here are some ideas:

$dump = array('test' => array());
test: { }

$dump = array('test' => array('0' => ''));
test: [ ]

$dump = array('test' => array(null));
test: [ ]

$dump = array('test' => array(':empty:'));
test: [ ]

Adding detection for one of these types to output it a different way should be possible right? It would simply detect if count($keys) == 1 and $keys[0] == null or ':empty:' or empty($keys[0]). I agree that the default should not be changed and seeing as how [] is a new feature it should be backwards compatible?

[jakzal]

What if you actually wanted the following:

$dump = array('test' => array('0' => ''));

to be dumped to:

test:
    - ''

The same question applies to the remaining proposals.

[patrickheeney]

If you wanted that its the same thing as $dump = array('test' => array());. The empty array with a high nest level will produce (the following hashed list):

test:
   - ''

So I would just suggest to anyone using array('0' => '') to use array() if they want an empty hash list that does the same thing.

On the other examples I mentioned it is possible with :empty: that they would want to pass that as a string. However with null they would either want null as a string array('null') or not at all (since null gets forced to the string version anyway). The null (not string) version could be used to create an empty list.

The other suggestion from either of these is to pass an option to dump that can be used to tell it to use [] or {} but I don't know that this would completely solve my issue since its a global change. As it stands now, not offering a way to have an empty list causes my YAML to be invalid because my applications can't parse YAML hashes when its expecting a list. Both are valid YAML with completely different purposes so my hope is that both can be supported in some fashion.

Another potential idea:

$dump = array('test' => array(array()));

That would currently output YAML I believe like this:

test:
  - ''
    - ''

I don't know if that it is valid YAML anyway so it could be leveraged to create test: [ ].

[categulario]

I had the same problem.

maybe using standard objects for empty objects instead of arrays, like:

$dump = ['array' => [], 'object'=>(object)[]];

and the output

array: []
object: {}

[patrickheeney]

@developingo good idea. That would be perfect.

[fabpot]

implemented as of #10552

[rkyoku]

Sorry for the n00b question, but it seems to me that referenced issue (#10552) only updates the parse() method, and not the dump() method as specified in this ticket (#9870).

I indeed also encounter this issue: dump() should check if empty array is actually an empty object, and dump accordingly. It is important for some requirements (like, for example, Swagger)

Could you please reopen this issue?

[xabbuh]

I indeed also encounter this issue: dump() should check if empty array is actually an empty object, and dump accordingly.

How would you determine if an array should actually be an empty object?

[rkyoku]

Just like it was proposed earlier. Use an empty stdClass instance. I
believe it is intuitive, actually. Array is array, stdClass is object.
Associative array is object, indexed array is array. Don't you agree ?

Le mar. 30 juin 2015 09:06, Christian Flothmann notifications@github.com
a écrit :

I indeed also encounter this issue: dump() should check if empty array is
actually an empty object, and dump accordingly.

How would you determine if an array should actually be an empty object?

—
Reply to this email directly or view it on GitHub
#9870 (comment).

[xabbuh]

The issue is that the dumper only handles PHP objects when you enable object support. If the support is not enabled, the dumper will always return null. Though if object support is enabled it will simply serialize the object and prefix it with !!php/object:. Changing this behaviour only for stdClass instances would be possible, but could be considered a BC break.

ping @symfony/deciders What do you think?

[rkyoku]

What about adding a new parameter (false by default for BC) just like it
was added to the parse() method?

Le mar. 30 juin 2015 13:21, Christian Flothmann notifications@github.com
a écrit :

The issue is that the dumper only handles PHP objects when you enable
object support. If the support is not enabled, the dumper will always
return null. Though if object support is enabled it will simply serialize
the object and prefix it with !!php/object:. Changing this behaviour only
for stdClass instances would be possible, but could be considered a BC
break.

ping @symfony/deciders https://github.com/orgs/symfony/teams/deciders
What do you think?

—
Reply to this email directly or view it on GitHub
#9870 (comment).

[xabbuh]

see #17728