Path syntax: merge slice syntax and prop list syntax

[hgwood]

Prerequisites

• [X] I have read the Contributing guidelines
• [X] I have read the Code of conduct and I agree with it

Description

Since #159, immutadot supports both slices for arrays (arr[1:4]) and prop lists for objects (obj{a,b}). Since arrays and objects are actually the same concept, would it be possible to merge the two syntaxes?

Only for feature requests :sparkles:

Example

const obj = Object.assign([[1], [2], [3], [4], [5]], {a: [], b: [1], c: []})
push(obj, '[a,b,1:4]', 0)
// returns [[1], [2, 0], [3, 0], [4, 0], [5], a: [0], b: [1, 0], c: []]

[nlepage]

Having commas in the array/slice notation is a very good idea, and would allow the users to do anything they want. This is a big change in toPath and in apply, I think it would be wiser to postpone after 1.0. Even if we have to keep the list notation for backward compatibility, I think it's not a problem. @hgwood would this be ok with you ?

[hgwood]

*anything they want :)

Yes, of course I'm fine with postponing.

[frinyvonnick]

I feel this issue deprecated since tc39 have a proposal for slice notation https://github.com/tc39/proposal-slice-notation

I think we should stick to standard approach

[nlepage]

I think this needs further discussions.

What this issue was originally about is

The bracket notation (not slice notation) allows accessing array indexes, array slices, properties, non identifier named properties. Why introduce the list notation, why not use the bracket notation with comma instead?

Sticking to the standards

Sticking to the standards is obviously a good idea.

The slice notation (with the step added) follows tc39's proposal.

But the properties list access follows no standard, it was inspired by bash's notation for multiple directories, and it looks like destructuring:

const { a, b } = obj
set(obj, '{a,b}', 123)

But what about access to non identifier named properties ?

When accessing one property we stick to the standard:

obj["my prop"] = "foo"
set(obj, '["my prop"]', "bar")

But when accessing multiple properties, it doesn't look like destructuring anymore:

const { myProp1, ["my prop2"]: myProp2 } = obj
set(obj, '{myProp1,"my prop2"}', 123)

Destructuring requires aliasing the property to a valid identifier, but in the path this is not necessary.

This is not so bad after all... if we wanted to look more like destructuring we could put back the brackets:

set(obj, '{myProp1,["my prop2"]}', 123)

Finally what about the all props access ?

Using the star may not have been such a good idea.

Following the idea of sticking to the destructuring, we could have used the three dots:

set(obj, '{...}', 123)