[WIP] Allow foo.'bar-bat' and foo.1 to access object members #3828

pscollins · 2015-02-03T23:49:28Z

This change addresses #3520. I wasn't sure if there is a consensus on that issue, but I think that it's a simple change that could clean up code in some places.

epidemian · 2015-02-04T03:15:57Z

👍

This makes for a nice symmetry with literal object notation.

obj = 
  # Can use barewords for keys that look like identifiers.
  foo: 42
  # But need enclosing commas for non-identifier-like keys.
  'wordy key': 43

# Can access identifier-like keys by a bareword after the dot.
obj.foo # => 42
# But need enclosing commas for accessing non-identifier-like keys.
obj.'wordy key' # => 43

jashkenas · 2015-02-04T16:11:04Z

I'm not sure really what to think about this. There is a certain symmetry, but there's also a certain awkwardness, especially when it comes to more complicated accesses:

configuration.'ajax-get-request'(url, options)

... that's just odd. Any staunch defenders of this idea?

vendethiel · 2015-02-04T18:09:37Z

It works in coco/LS, but I admit I don't use it that much. It's only interesting if you have to deal with "strange" json schemas...

lydell · 2015-02-04T20:41:31Z

If this is going to be supported, numbers should be as well. a.1

michaelficarra · 2015-02-04T23:43:48Z

@lydell: Agreed. I'm 👍 for both of them.

pscollins · 2015-02-05T03:30:08Z

@lydell maybe it would be easiest to do something like

PropertyIdentifier ::= Identifier | AlphaNumeric

and then replacing the existing uses of Identifier with PropertyIdentifier in Accessor?

lydell · 2015-02-05T13:07:54Z

especially when it comes to more complicated accesses:
configuration.'ajax-get-request'(url, options)
... that's just odd.

I always try to avoid the a[b](c) pattern, because IMO it is not very readable. configuration.'ajax-get-request'(url, options) isn’t more odd than configuration['ajax-get-request'](url, options) or the syntactically valid JS "string"().

jashkenas · 2015-02-05T14:59:38Z

Alright then. I'm persuaded. Let's add numbers to this patch, and some more robust tests, and merge.

michaelficarra · 2015-02-05T16:34:45Z

😀

lydell · 2015-02-06T15:19:40Z

@pscollins Please do what you suggested and add tests for all the access variants (not just .) and tests that you can call such accesses as well as access deeper properties. Also test heredocs.

pscollins · 2015-02-06T17:21:51Z

@lydell :: and ?:: as well, or just . and ?.? My guess is no, since things accessible through :: won't have been written as object literals, and so shouldn't have crazy names.

michaelficarra · 2015-02-06T17:43:11Z

@pscollins: Of course those should be allowed.

a::' ' = ->
a.prototype = ' ': ->

jashkenas · 2015-02-06T19:28:16Z

Yes. If it's for any accessor, it should be for all accessors. And tested ;)

pscollins · 2015-02-06T23:38:59Z

I've got it working and tested for every form except

 obj.NUMBER

It's listed in the testcases I just pushed, commeted out. Uncommenting it yields:

test/objects.coffee:474:9: error: unexpected .42
eq obj.42, 3

I assume that what's happening is Lexer#numberToken is consuming the . and lexing it as IDENTIFIER NUMBER rather than IDENTIFIER . NUMBER.

I'm not sure how this could be dealt with in the parser. The best case I can imagine would be adding in a special IDENTIFIER . [0-9]+ case in the lexer that comes before numberToken is called, but that seems a little hacky.

It's also worth noting that something like

obj = 
  4.1: 1
  4:
    1: 2

will be ambiguous.

What's the best way to approach it? Make a special case for numeric accessors, and forbid non-integers? Require that numeric accessors go in parens? Restrict it to strings?

For comparison, it looks like coco basically forbids non-integers:

obj =
  4: 1
  5: 2
  5.1: 3
  6:
    1: 4

console.log obj.4 // 1
console.log obj.5.1 // undefined
console.log obj.6.1 // 4

but that seems really confusing to me.

jashkenas · 2015-02-06T23:49:03Z

Re: the parser error, I don't know — but as to your second question...

obj = 
  4.1: 1

... would simply be:

obj = 
  "4.1": 1

no? I don't see the ambiguity.

pscollins · 2015-02-07T03:15:12Z

@jashkenas Sorry, I didn't mean that defining the object would be ambiguous -- I meant accessing it would be ambiguous.

My worry is that obj.4.2 can be interpreted either as obj[4][2] or obj[4.2]. If your object looks like obj = {4.2: "foo"}, you're going to be confused if obj.4.2 throws an error for trying to access the property 2 on the undefined obj[4]. If your object looks like obj = {4: {2: "foo"}}, then you're going to be confused if obj.4.2 gives you back undefined for trying to access obj[4.2].

Or you might have

obj = 
  4:
    2: 1
  4.2: 2

Now, what should obj.4.2 be? 1, or 2?

It seems to me like it would be easy for someone new to the language to get tripped up by floating point numbers behaving differently from other kinds of numbers, but maybe I'm overreacting?

michaelficarra · 2015-02-07T03:20:19Z

It should be a decimal integer, not floats, not hex, not scientific notation, etc. So my answer is it would be obj[4][2].

lydell · 2015-02-07T08:05:38Z

src/grammar.coffee

+    o '.  AccessorIdentifier',                  -> new Access $2
+    o '?. AccessorIdentifier',                  -> new Access $2, 'soak'
+    o ':: AccessorIdentifier',                  -> [LOC(1)(new Access new Literal('prototype')), LOC(2)(new Access $2)]
+    o '?:: AccessorIdentifierIdentifier',       -> [LOC(1)(new Access new Literal('prototype'), 'soak'), LOC(2)(new Access $2)]


It's correct in the compiled JS though. Remember to rebuild everything.

lydell · 2015-02-07T08:08:12Z

I think a . b is valid, so there should be tests for a . 'abc' too

lydell · 2015-02-07T08:09:27Z

and tests that you can call such accesses as well as access deeper properties

You forgot this.,

lydell · 2015-02-07T10:53:01Z

src/grammar.coffee

+  # identifiers, string literals, and numbers.
+  AccessorIdentifier: [
+    o 'Identifier'
+    o 'AlphaNumeric'


A possible solution for the number problem could be to replace this line with:

o 'STRING' o 'INTEGER'

Then, in AlphaNumeric replace o 'NUMBER' with o 'Number' and add:

Number: [ o 'NUMBER' o 'INTEGER' ]

and adjust the NUMBER regex in the lexer to match integers separately from other decimal numbers and make Lexer::numberToken tag integers as such.

michaelficarra · 2015-02-07T16:30:49Z

I forgot we even allowed leading dots in number literals. Who thought that was a good idea?

lydell · 2015-02-07T20:17:53Z

I forgot we even allowed leading dots in number literals.

Me too. That’s really making things more complicated here.

lydell · 2015-02-07T22:20:48Z

I think the best way to solve it is to add return 0 if number.charAt(0) is '.' and @tag() in INDEXABLE in Lexer::numberToken.

jashkenas · 2015-02-10T15:46:39Z

I forgot we even allowed leading dots in number literals. Who thought that was a good idea?

It's not a good idea ;) We shouldn't have let that sneak in.

lydell · 2015-02-10T16:01:40Z

See #383.

jashkenas · 2015-02-10T16:07:14Z

It should be a decimal integer, not floats, not hex, not scientific notation, etc. So my answer is it would be obj[4][2].

Agreed.

lydell · 2015-02-10T16:22:22Z

We shouldn't have let that sneak in.

That makes it sound like they were never intended but there were no tests for it and during some refactor they were allowed by mistake. Since that's not the case, do you think that we should remove them (which makes this PR a lot simpler to finish, but likely results in 10 duplicate issues the same day it is released) or let them stay?

jashkenas · 2015-02-10T16:44:43Z

Ha ha. There's a certain class of feature (of which there are dozens of examples in CoffeeScript) that I intentionally didn't include at the beginning because they're not my personal preferred style ... but that managed to sneak in over time because people ask for them, and you say "why not?".

This was one of those.

I don't think we can remove them at this point. But perhaps we could tag them specially in the lexer (or something) to make this change easier.

michaelficarra · 2015-02-10T17:18:26Z

Numbers with a leading . instead of 0. are exceptionally uncommon in JS, and I bet even more so in CoffeeScript. Same goes with numbers with trailing .. I think we can safely remove them with a simple comment in the changelog.

jashkenas · 2015-02-10T18:59:52Z

I'd love it if that were really the case. My anecdotal sense is that lots of folks prefer to write speed + 0.5 as speed + .5.

Can we employ Github's code search to find out if folks are using it in CoffeeScript?

lydell · 2015-02-10T19:00:29Z

At least in CSS I’ve seen lots of .5s. (Don’t know about JS though.)

lydell · 2015-02-20T03:37:33Z

#1982 (comment)

lydell · 2015-05-01T15:29:24Z

Just found that this would close #1334 as well.

shreeve · 2016-10-02T20:00:02Z

Any status on this PR? Seems like the issue was related to a possible breaking change if some people used numbers like this: x = y + .25

Is breaking this use case the reason for this PR not being accepted?

lydell · 2016-10-03T06:09:00Z

It seems like it was decided that disallowing .5 etc. is too much of a breaking change to be a real option.
Some trickery is required to get foo.1.2 working.
There are lots of merge conflicts.

pscollins · 2016-10-03T15:22:37Z

@shreeve IIRC I had trouble getting it to work in the .5 case and I got busy with other projects --- feel free to revive this/close this PR for a new one/etc.

GeoffreyBooth · 2016-10-03T17:20:06Z

FYI we should probably put this on hold until tagged template literals are supported, unless we’re certain that there won’t be any ambiguity between this proposed syntax and the syntax we’ll need for that. I would think tagged template literals should have a much higher priority if we’re forced to choose between them.

GeoffreyBooth · 2017-05-01T07:20:52Z

@pscollins or anyone on this thread, I’d love to get this updated and targeted against the 2 branch. It seems like it was rather close?

GeoffreyBooth · 2017-07-26T06:59:13Z

What’s going on with this? Is this something we’re still interested in getting finished, or should I close this as an abandoned effort? If we are trying to finish it, are there any breaking changes that would result from merging this in?

michaelficarra · 2017-07-31T05:33:43Z

I can't speak to the quality of this PR, but this is a great feature and should be pursued.

GeoffreyBooth · 2018-02-02T04:28:43Z

At this point the codebase has changed so much since this PR was started that a new PR will be necessary, so I’m closing this one. I’m leaving issue #1334 open as a reminder that we’re interested in pursuing this; that issue has a link to this thread.

Allow foo.'bar-bat' to access object members. Closes jashkenas#3520

0e13f74

jashkenas added the enhancement label Feb 4, 2015

jashkenas#3828: Literals working except for obj.NUMBER.

8944123

lydell reviewed Feb 7, 2015
View reviewed changes

lydell mentioned this pull request Feb 10, 2015

Allow dynamic keys for object (hash) definition #3597

Closed

GeoffreyBooth changed the title ~~Allow foo.'bar-bat' to access object members. Closes #3520~~ Allow foo.'bar-bat' and foo.1 to access object members. May 1, 2017

GeoffreyBooth changed the title ~~Allow foo.'bar-bat' and foo.1 to access object members.~~ Allow foo.'bar-bat' and foo.1 to access object members May 1, 2017

GeoffreyBooth changed the title ~~Allow foo.'bar-bat' and foo.1 to access object members~~ [WIP] Allow foo.'bar-bat' and foo.1 to access object members May 1, 2017

GeoffreyBooth mentioned this pull request May 6, 2017

Cleaner syntax for accessing "illegal" object members: object.'some-value' #3520

Closed

utkarshkukreti mentioned this pull request Jan 22, 2018

Proposal: Dot notation for numerical property names #1334

Closed

GeoffreyBooth closed this Feb 2, 2018

zdenko mentioned this pull request Mar 6, 2018

Access object members with '.' and literal #5006

Closed

[WIP] Allow foo.'bar-bat' and foo.1 to access object members #3828

[WIP] Allow foo.'bar-bat' and foo.1 to access object members #3828

Uh oh!

Conversation

pscollins commented Feb 3, 2015

Uh oh!

epidemian commented Feb 4, 2015

Uh oh!

jashkenas commented Feb 4, 2015

Uh oh!

vendethiel commented Feb 4, 2015

Uh oh!

lydell commented Feb 4, 2015

Uh oh!

michaelficarra commented Feb 4, 2015

Uh oh!

pscollins commented Feb 5, 2015

Uh oh!

lydell commented Feb 5, 2015

Uh oh!

jashkenas commented Feb 5, 2015

Uh oh!

michaelficarra commented Feb 5, 2015

Uh oh!

lydell commented Feb 6, 2015

Uh oh!

pscollins commented Feb 6, 2015

Uh oh!

michaelficarra commented Feb 6, 2015

Uh oh!

jashkenas commented Feb 6, 2015

Uh oh!

pscollins commented Feb 6, 2015

Uh oh!

jashkenas commented Feb 6, 2015

Uh oh!

pscollins commented Feb 7, 2015

Uh oh!

michaelficarra commented Feb 7, 2015

Uh oh!

lydell Feb 7, 2015

Choose a reason for hiding this comment

Uh oh!

lydell Feb 7, 2015

Choose a reason for hiding this comment

Uh oh!

lydell commented Feb 7, 2015

Uh oh!

lydell commented Feb 7, 2015

Uh oh!

lydell Feb 7, 2015

Choose a reason for hiding this comment

Uh oh!

michaelficarra commented Feb 7, 2015

Uh oh!

lydell commented Feb 7, 2015

Uh oh!

lydell commented Feb 7, 2015

Uh oh!

jashkenas commented Feb 10, 2015

Uh oh!

lydell commented Feb 10, 2015

Uh oh!

jashkenas commented Feb 10, 2015

Uh oh!

lydell commented Feb 10, 2015

Uh oh!

jashkenas commented Feb 10, 2015

Uh oh!

michaelficarra commented Feb 10, 2015

Uh oh!

jashkenas commented Feb 10, 2015

Uh oh!

lydell commented Feb 10, 2015

Uh oh!

lydell commented Feb 20, 2015

Uh oh!

lydell commented May 1, 2015

Uh oh!

shreeve commented Oct 2, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

shreeve commented Oct 2, 2016 •

edited

Loading