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

MemberExpression with . parses to Identifier instead of LIteral #98

Open
mflerackers opened this issue Mar 25, 2019 · 1 comment
Open

Comments

@mflerackers
Copy link

anObject.aField parses to

{"type":"MemberExpression","computed":false,"object":{"type":"Identifier","name":"anObject"},"property":{"type":"Identifier","name":"aField"}}

which would be anObject[aField]

Though anObject.aField should be the same as anObject["aField"]

{"type":"MemberExpression","computed":true,"object":{"type":"Identifier","name":"anObject"},"property":{"type":"Literal","value":"aField","raw":"'aField'"}}

@craigphicks
Copy link

In the first case property computed has value false, while in the second case it has value true.
That difference corresponds to the . access versus the [] access. It is true that in the case of an object the result is the same because the r.h.s is a string.

But what if it weren't a string, if it were something that needed to be computed? (Hence the property computed). Or what if the left hand side were an array an not an object? Or some project dependent "whatever"? Because of these other scenarios it is necessary to disambiguate the the two cases.

In your eval code it is easy enough to identify and correctly compute the equivalence of two cases you mentioned.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants