Optionally insert nils instead of empty slices and maps

[oakad]

When populating slice fields, faker may decide to use an empty slice as a slice value ([]sometype {}). Some other libraries, however, feature an optimization, whereupon empty slices are always replaced with nils to keep the amount of memory garbage down.

When unit testing various serialization scenarios we often have a situation whereupon an object has to be compared to an equivalent object:

1. Populate a reference struct with fake data
2. Serialize it to a byte array
3. Deserialize it to another struct
4. Compare the newly obtained struct to a reference one

However, if serialization library treats empty slices as nils the comparison would not succeed, because empty slice object and nil do not compare as equal using reflect.DeepEqual.

Given the above, I believe that an easy to implement option to emit nils instead of zero length slices will be quite handy, because serialization testing is actually quite common in network oriented programs.

The above equally applies to maps.

[bxcodec]

• CMIIW & I'm sorry if I do not get it right what you're saying here.

Currently, faker will always generate an array(slice) of dummy data for any array(slice) type.
For the case of using an empty slice as a slice value, I think that can be done by adding manually in the code because it's empty anyway, you don't need any item in it, so what the point to use faker.

I use faker when I have a struct that has array fields, but I'm too lazy to fill the array items. If I just need an empty slice or nil, I just put it in the code manually.

What do you think?

[oakad]

If the struct is deeply nested it is very cumbersome to do manually. Also, adds a lot of boilerplate to unit tests.

The point is, empty and nil slices are important unit test items. Faker nicely creates empty slices so it will be nice of it to create nil slices and maps as well.

[bxcodec]

hmmm, I see.
Cool. But I'm not sure I can add this ASAP, I'm so busy lately. Maybe you could submit a PR to solve this. I will really appreciate that ;)

[bxcodec]

Should be fixed by #59