It is written that apply works with “collections”.
What collection means isn’t explicitely stated (I think ?) but it describes multiple times maps arrays and page collections. But apply isn’t allowed with maps even though it’s not documented.
Logically it should apply the transformation to the map’s elements and ignore the keys. Generally the notion of page collections and maps seem very similar, both have elements and keys. At least functions that do not imply order (like “where” and “apply”) should be unified.
It is in the glossary, which is a bit hard to find. There, it is said that a collection is an array, slice or map. Then, if apply works on Collections, one would initially expect it to handle maps, too. However, if you look at apply’s definition, you see:
Returns a new collection with each element transformed by the given function.
The term “element” makes no sense in the context of a map, imo. Or rather: There’s no reason to assume that apply should work on all values of a map instead of all keys. Or key value pairs, for that matter.
Also, the examples only refer to ordered collections (aka slice). Which a map is not.
But the fact remains that Collections is confusing in this context. I looked through some of the functions in Collections, and most work only on a slice. In, however, works on a set, which can be an array, slice or string, while a string is by definition not a colletion. And then there’s Merge that only works on maps, or Querify which works with a map or a specially crafted slice.
So I was right, the type system is a royal mess… I won’t be as insensitive as to suggest a total overhaul, but regards to maps and apply, I beg to disagree with you.
Maps are immutable and keys behave like constants. Tell me if I’m wrong, but Store objects are not ordinary maps.
o there is nothing one can apply a function if not a map’s values, or the map itself. Even if you could argue edge cases, we would gain much more functionality and coherence by documenting these exceptions and allowing the general case.
That was not what I meant to say. The documentation is a bit vague sometimes. And I’m not convinced that a Collections group or type or whatever, whose functions work on different data types is a good idea. But that’s not my call.
That maps are immutable is true, and I do not quite understand why that is the case. And the only map method I know (in JavaScript) does work only on Arrays and Iterators, not on objects (akin to maps).
- slices in Hugo are immutable, too
- immutable objects are much easier to handle in a massive parallel processjng engine (educated guess)
See my comment here:
https://discourse.gohugo.io/t/use-apply-as-a-map-equivalent/39850/7
This is a documentation issue. See revised description.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.