👍 but it has been refused by @fabpot in the past (#26717)

👍 but it has been refused by @fabpot in the past (#26717)

Oh I didn't know that, I talked to @xabbuh before starting to work on it...

To me there is technical reason (regarding the comment in the other PR). I am reading Yaml files, adding some content and dumping it again to the filesystem. Now, depending on the source, wether its using null or ~ the diff get s quite big and a diff/commit is a technical thing to me.

Let me be more clear with an example.

Adding content too this file:

foo: bar
baz: ~

would result in:

foo: bar
- baz: ~
+ baz: null
+ lol: null

which is very verbose. The following would be less verbose:

foo: bar
baz: ~
+ lol: ~

Btw. I created nearly the exact same PR like you @fancyweb without knowing it 😄

Let me explain a bit more why I think that this is not something I want: adding more options is adding more complexity (and complexity grows exponentially with more added options). Having only. One way to do something makes our code simpler, easier to understand, easier to document, and easier to use. Less decisions.

I agree with you Fabien 👍. Another option would be to rework the YAML component and create an extension point for projects.

I hope you read my argument, because I was updated my post.

I am not the one who decides to get this merged, but as the tilde is a common used thing in YAML, I talked to @xabbuh and he asked me to create a PR, @fancyweb created the same PR... so it looks to me that for this small option the community (at least some of them 😄 ) have a need.

Another point is, that YAML is best to be human readable, but a diff changes every line including a ~ isn't readable anymore.

We moved away from generating ~ in favor of null a few years ago as people didn't understand the meaning of ~ (we probably did that with @javiereguiluz back then).

I know that this is opinionated, but if you have a look at the flow of PRs, we have a regular stream of PRs adding options. I'm the one trying to challenge them to be sure that we really need those new options.

I'm the one trying to challenge them to be sure that we really need those new options.

And as I said its ok for me to challenge and not merge it. I gave all my arguments 😄 and I really like that you sometimes decide to not merge something 👍

The reason Fabien gives here:

as people didn't understand the meaning of ~

This is one of the few things I didn't know until recently. I think an explicit NULL is far better than having a tilde. However, I also do agree with Oskar on the following:

Another option would be to rework the YAML component and create an extension point for projects.

I think it's pretty great to have a sub-set of YAML functionality provided by Symfony, to which you can create a more complete implementations via 3rd party tools. Not sure how this would be done internally though, as it sounds very complex.

I think an explicit NULL is far better than having a tilde.

Thanks for your feedback @linaori, but I don't want to change the default value (so this is not an argument IMHO) and only want to have the option for people who know the ~ but currently I have really big git diffs after read/modify/dump 😢

If complexity is an issue, should the related code be rewritten to reduce this complexity? Even if it costs a bit of performance (you don't call this run-time, hopefully). The current flag system is also limiting at some point.

No I am using it async to handle my YAML files.

The proposed option is quite small and I think to rewrite it to fulfill my use-case is too much overhead, the flags are sufficient here.

I smell a small inconsistency here. Using the tilde seems to be a Symfony best practise, yet the YAML dumper uses the literal null instead. In other words: If would parse and dump a YAML file from the recipes, all ~ would be changed to null and there's nothing I could do about it, correct? 😕

If would parse and dump a YAML file from the recipes, all ~ would be changed to null and there's nothing I could do about it, correct

exactly thats my point!

I think this should be added, because Symfony interprets ~ as null already. Why not allow dumping it as ~ again, too? 👍

But CI needs to be green!

Sure thing Nicolas, will have a look soon 👀

I asked Oskar to open this PR as I agree with the reasoning for the changes. Dumping null by default is good, but being able to get ~ instead allows to keep files more similar to what we use in the documentation. While I generally agree with not adding more options than necessary the impact here is rather limited and doesn't add much complexity. So 👍 from me.

• Rebased
• CS fixed
• Docs-PR created
• CI 💚 @nicolas-grekas

What about changing ~ to null in the recipes? As I mentioned before, we had a few complaints about the meaning of ~ and decided to move to use null everywhere. Apparently, we forgot about this in the recipes, but that can be easily fixed (see symfony/recipes#635 and symfony/recipes-contrib#720).

What about changing ~ to null in the recipes?

That makes definitely sense, but the intent of my PR is to handle files, delivered from customers (in my project) which are using ~ instead of null. So this is not only Symfony related.

@OskarStark Of course. I just wanted to follow up and finish the discussion on the Symfony part, where we can definitely standardize on using null instead of ~. I've also added a validation rule so that if one uses ~ in a recipe, we will have a validation error.

For this PR, I'm +0.

I've also added a validation rule so that if one uses ~ in a recipe, we will have a validation error.

This is a nice addition. I would gladly help to fix those recipes, shall we run a sed command across the whole contrib repo?

For this PR, I'm +0.

I know ;-)

Travis failure is unrelated

Thank you @OskarStark.