Add properties and methods to Mapping/Listing API to resemble Map/List more

[holzensp]

No description provided.

[HT154]

Is there a particular reason why there are Lists while keys is a Set? Mappings are ordered (and documented as such), so this sort of makes sense to me. Having this reasoning documented might be helpful.

[odenix]

IMHO these should be Listings, and keys should be changed to Listing via a deprecation cycle.

[StefMa]

While we are here, what is the reason that pkl has Mappings and Map and Listing and List? 🤔

[bioball]

While we are here, what is the reason that pkl has Mappings and Map and Listing and List?

Several reasons (not comprehensive):

• Mapping and Listing are values of type Object; their members are lazy and late-bound, which has implications around how the object is represented in the underlying implementation. Map and List are a lot more performant for "algorithm-y" type logic; e.g. concat, map, filter, etc.
• Mapping and Listing have a special property called "default". It's not really clear how something like .map() and .flatMap() should work; what do you do with the special "default" property?

It'd be good to simplify the language and not have this dichotomy, but we'd need to at least solve the above challenges first.

[odenix]

Instead of forcing and copying each value, the Dynamic could delegate to the Mapping via addEntry(Object key, SharedMemberNode valueNode).
A similar overload could be added for addProperty (I didn't need it at the time).

[holzensp]

Closing this as an outdated duplicate of #683.