Allow `object."field"` syntax?

[Simn]

1. After drugging Nicolas with painkillers and wine, he was open to the idea of allowing object."field" as a syntax. This would make it easier to use externs that have field names which are keywords in Haxe or invalid syntax in some other way. Nobody really likes how this looks, but it seems to be the most practical solution.

2. Nicolas also suggested that we should be Koreancoherent and allow this at field-declaration-level.

---

See HaxeFoundation/haxe-evolution#32 for a related discussion. One open question is if we should restrict this to only " instead of ' so people don't get the idea to use interpolation there. However, I don't know what to tell the guys who think var s:String = "abc"; field.s = true; would generate field.abc after this change because that's just pure insanity to me.

[RealyUniqueName]

I vote for restricting to only ".

Also, should it require to have a full field access expression in case of this?

this."enum"; //ok
"enum"; //??

[RealyUniqueName]

Maybe consider using backticks?

obj.`enum`
`enum` //means this.`enum`

Seems to be an adequate replacement. And solves the problem with users trying to use String vars as field names.

[back2dos]

It's mostly for externs, so having this pointing to an instance that has such a field will be the exception.

[RealyUniqueName]

It could become a problem with extending extern classes.
E.g. in flash extending a flash.display.Sprite is a common thing. And it's an extern.

[Gama11]

The nice thing about double quotes is that it's consistent with how you can already use string literals for fields in anonymous structures.

var point = { "x" : 1, "y" : -5 };

[back2dos]

It could become a problem with extending extern classes.

I'm aware that there may be such cases, but as I said, I'd say it's going to be the exception. You'd have to have an extern class with such a field, then you'd have to have the need to extend that class and then the need to access that particular field. In that case you can still use this."enum" which doesn't seem to be the end of the world to me. Or you use @:native on the field, which you can, because it's a class.

[RealyUniqueName]

It's definitely a rare case, but it would be great to have a single way to do this, and not "use double quotes, but sometimes use @:native or add this." :)

[ncannasse]

Backticks seems appropriate. That seems like the best solution.

[kevinresol]

The nice thing about double quotes is that it's consistent with how you can already use string literals for fields in anonymous structures.

You can also use single quote, only that interpolation won't work

[Simn]

I also don't see what the problem with requiring this."field" is. We're talking about a syntax for field access here, which is unrelated to identifier resolution. Just because identifiers can resolve to fields doesn't mean that we cannot have a distinct dot-access syntax for fields.

The only thing that bothers me somewhat is that you couldn't use this from within abstracts because there is no syntax to qualify the abstract "self", given that this always refer to the underlying type. That however is also a separate problem. It's also questionable if you'd ever have a compile-time feature like abstracts combined with run-time-native field names.

[back2dos]

I think that:

1. having a way to use identifiers that are keywords is crucial, because it covers certain edge cases where native code requires an identifier that's reserved in Haxe, in which staying within the type system is difficult at best.
2. if having keywords is really necessary (hscript doesn't have them at lexer level, so I'm not quite sure why Haxe does), then some way of escaping is an adequate solution.
3. this being an edge case, I don't like the idea of introducing a new token type just for that. If some day we find a more common use case for backticks, we won't be able to support it.