On Jun 15, 2011, at 2:43 AM, Axel Rauschmayer wrote:
>>> Has that been considered as a use case (e.g. after a compilation/generation
>>> step?). But it doesn’t seem like identifier names are accessible to quasi
>>> handlers, which would make this difficult.
>>
>> If the consensus ends up being that more than simple identifiers are
>> allowed in substitutions, then I don't know what it would mean for
>> identifiers to be available.
>
> I didn’t find in the spec how the "substitutions" parameter (that quasi
> handlers get) is structured, thus I assumed that it was an array of values.
That's right, it is the trailing arguments after the "callSiteId". A rest
parameter can be used to capture these as an array. The examples probably
should use rest params instead of |arguments|.
The point is that the callSiteId captures all the
literal/constant/loop-invariant parts of the quasi, both raw and cooked
("expandedLP"). The remaining quasi handler parameters are the necessarily
variable, evaluated-at-runtime substitution expression results.
The proposal needs to say this a bit more explicitly, and up front.
> It could be an array of (key,value) pairs, then going beyond simple
> identifiers would be easy.
No, the proposal desugars, so whatever is after the $ and possibly in {} is an
expression evaluated without change, and its result value goes is passed to the
quasi handler.
The reason for grammatical restrictions on the substitutions, to be identifiers
or perhaps dotted identifier chains (a restricted MemberExpression) is so that
the spec and users' models of it are simple and we don't end up with hellish
lexical rules for finding that closing }.
> I am assuming that order matters, if not, then there is something fundamental
> about handler parameters that I haven’t understood.
Yes, order matters.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
