You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This post concerns the predefined literal reserved words. That is expressions with type==="Literal" and for which the value is set by the parser directly from the hard coded table
There is no interface to discover or alter these reserved keywords.
The content is arbitrary - e.g. null is a member while undefined isn't.
It's very opinionated. There is no reason to suppose null should be a reserved word in the developers context. Or that true and false, if reserved, should be all lower case.
It forces the developer to consider extra logic to prevent these keywords from being used as identifiers. Needlessly.
Instead of these reserved works getting categorized as type==="Identifier" with a flag for reserved and areservedValue field, they are parsed as type=="Literal", sharing the type "Literal" with raw strings and numbers. This could be anti-intuitive to many developers, because if those reserved words were not specially parsed by Jsep, they would end in the case for type==="Identifier" where the developer would have their own simple table of reserved words for pre-emptive lookup - simple and straightforward.
There is no warning about any of this in the documentation.
Mostly Jsep just works as a developer would expect - which is wonderful and the documentation is not missed (that much). But this is an exception. And actually this is also an exception (or could throw one) and could be included here too - please forgive my poor attempt at humor.
The text was updated successfully, but these errors were encountered:
This post concerns the predefined literal reserved words. That is expressions with
type==="Literal"
and for which thevalue
is set by the parser directly from the hard coded tableProblems wit the current setup:
null
is a member whileundefined
isn't.null
should be a reserved word in the developers context. Or thattrue
andfalse
, if reserved, should be all lower case.type==="Identifier"
with a flag forreserved
and areservedValue
field, they are parsed astype=="Literal"
, sharing the type "Literal" with raw strings and numbers. This could be anti-intuitive to many developers, because if those reserved words were not specially parsed by Jsep, they would end in the case fortype==="Identifier"
where the developer would have their own simple table of reserved words for pre-emptive lookup - simple and straightforward.Mostly
Jsep
just works as a developer would expect - which is wonderful and the documentation is not missed (that much). But this is an exception. And actuallythis
is also an exception (or couldthrow
one) and could be included here too - please forgive my poor attempt at humor.The text was updated successfully, but these errors were encountered: