Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Merge arrays #35
This will probably never happen for a few reasons.
First off, merge keys for objects use regular YAML syntax. '<<' is a string key which some YAML loaders perform a merge operation on, and often in a manner incompatible with other YAML loaders. Many loaders treat a
In YAML 1.3, loaders will be encouraged not to support merge keys by default. It will become an optional feature. YAML is a data language in the same sense that JSON is. Programatic features should not have ever been encouraged.
You might want to do something like this:
and then post process
@ingydotnet Now every application that needs this feature will have it... except it will be proprietary, and it would have wasted the developer's time. To what end?
It's absolutely acceptable to want to say "hey, this config over here is the same as the one over there, except toss this in too."
Please reconsider this decision.
Very common examples are:
Without the ability to merge lists complex configurations often devolve into copy&paste hells that are very difficult to maintain.
First: Yes, I can see why one would want to have such a feature. I would want it too.
Here I just want to talk about this specific suggestion in this issue.
So let's talk about merge keys for mappings first.
As @ingydotnet said,
That means the parser does not know anything about merging. It is not syntax.
Now to the suggested merge array.
First, this is already valid syntax. It is a simple string
I think it is not a good idea to invent a new syntax element for a single programmatic feature.
There are suggestions on how to get more generic programmatic features into YAML that would just add one new syntax element (set) and leave the implementation to a higher level.
I can confirm, this is happening to me. I'm using both Gitlab CI & Bitbucket Pipelines, and I always end up copy/pasting blocks of configuration, resulting in huge unreadable yaml files.
I think it was explained well enough that:
I personally understand that it would be useful to have a standard way to do this, and new features in YAML 1.3 sound nice but don't exist yet. But this issue talks about a specific syntax.
(1) Everyone who wants this syntax, feel free to implement a parser that does this. But first look at the YAML Test Matrix http://matrix.yaml.io/ and think about why we have so few parsers that are working correctly, and if you really feel able to implement a correct parser (at least as correct as existing ones) with this new feature.
This is terrible reasoning. Not wanting to put symbols that mean things into the language because they are data processing? Hmmm, all symbols represent actions
Means create an array called "an_array", then each - symbol means add a numerical index to the array it's defined under with the value: 1, 2, 3
Adding <<: or whatever here is just another syntax element, just because it's data processing doesn't mean it's not worthy and this helps in a lot of really basic cases that have real world benefits.
Saying that because something is data processing, well, damn, all symbols represent data processing. All elements do things according to what the specification says it means
Then it should be a special syntax element, because it is in the position of syntax and not data, << could be a part of a string, but if you're in an array syntax and you can't find a "-" or a "key:" then "<<:" is obviously not a string.
Each time the processor is scanning through, it's taking care of indentation, it comes to <<: and then it thinks that this is a string?
Does anybody use << as a string whilst defining arrays? Anybody? and under what conditions? I can't even think why I'd want to use << as a string key in an array
This YAML is already invalid:
But let's take your
This would be a new syntax, because currently this is invalid. I can give you reasons why this still isn't practicable and would need a lot of changes in existing YAML processors. An obvious problem though is: let's say you want that merge element at the top of the sequence:
Now the node under