Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Path syntax: merge slice syntax and prop list syntax #167

Open
2 tasks done
hgwood opened this issue Dec 14, 2017 · 4 comments
Open
2 tasks done

Path syntax: merge slice syntax and prop list syntax #167

hgwood opened this issue Dec 14, 2017 · 4 comments

Comments

@hgwood
Copy link
Contributor

hgwood commented Dec 14, 2017

Prerequisites

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 ✨

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
Copy link
Member

nlepage commented Dec 15, 2017

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
Copy link
Contributor Author

hgwood commented Dec 15, 2017

*anything they want :)

Yes, of course I'm fine with postponing.

@nlepage nlepage added this to the Future milestone Dec 15, 2017
@nlepage nlepage modified the milestones: Future, 2.0 Apr 27, 2018
@frinyvonnick
Copy link
Contributor

frinyvonnick commented May 31, 2018

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
Copy link
Member

nlepage commented May 31, 2018

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)

@nlepage nlepage reopened this May 31, 2018
@nlepage nlepage modified the milestones: 2.0, Future May 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants