Add TokenKind for magic constants? (__DIR__, __FILE__, etc) (usability)

[TysonAndre]

trafficstars

Motivations:

• If these were unavailable, applications would have to extract the string from the file contents, trim whitespace to check if something was a magic constant (e.g. to know if a value was a string or an integer)

• Easier to have checks in the parser, which is aware of the parent node's context (E.g. $this->__LINE__ = $y; does not contain a magic constant, but $this->y = __LINE__; contains a magic constant, and $this->{__DIR_} = $y; does contain a magic constant.

  Applications would have overlooked bugs if they had to guess where a token (of kind TokenKind::Name) was magic.

PossibleSolutions:

• Single TokenKind constant for the set of all magic constants (Applications may extract the string to figure out which one)
• Multiple TokenKind constants, one for each constant

[mousetraps]

Cool idea! This would be super helpful for type inference.

That said, one thing to keep in mind with any usability improvements is that we need to be really careful about adding context-specific behavior to the parser because it could hurt reusability of nodes when it comes to incremental parsing.

In the case of magic constants, my hunch is that this is such a granular distinction that it wouldn't matter, but it's something that needs to be thought through.

[mousetraps]

Also, of the two options you suggested, it seems that the multiple TokenKind constants is the only one that satisfies all the motivations.

I can't think of many cases where it's important to know that it's a magic constant, but not important to know what type it is. Otherwise, getText should already achieve that result because it returns the token string without whitespace.

[TysonAndre]

I no longer personally need this, and any applications already using the library would have worked around it if needed (and distinguish between reading a non-fully qualified constant and using something as a literal name)