lexical 'super' in arrow functions?
claus.reinke at talk21.com
Tue Dec 4 01:58:52 PST 2012
>>>>> Is 'super' currently limited to method bodies, excluding local functions?
>>>>> Given that 'this' is lexical in arrow functions, I expected any enclosing
>>>>> 'super' to be available, as well, but I cannot confirm this from the spec.
>>> Yes, clearly super should be able to be used in an arrow function that is lexically scoped to an
>>> enclosing super binding. The mechanism for describing this are mostly in the spec., but I just
>>> checked and there are a few loose ends that I will clean-up in the next spec. draft.
>> That would be good.
> OK, I looked more closely and anything needed for super references within from within Arrow
> functions is already in the current draft. Just trace through the algorithms in section 11.2.4.
> Particularly, steps 1-4 of the Evaluation algorithms. However, I did add a few clarifying note in
> the next draft.
Before I make another attempt to extract this info from the current
draft, let me some general comments:
Like everyone else on this list, I have grown familiar with the current
spec - not as familiar as tc39 members, but enough to find answers
to questions when I need them.
But with the evolving drafts of the new spec, I'm back in the situation
most JS coders are wrt the spec: trying to find answers in the spec is
just a little demoralizing, often unsuccessful, and will remain a hidden
art for those who do not read/study most of it at some point.
Language specs, for those languages that have them, fall somewhere
on a scale from informal, readable to formal, unreadable.
ES, for all its faults, has a spec on the formal side -which is a very
good thing!- but unfortunately also on the not directly readable side.
The reason is that the spec is essentially a reference implementation -
even though it doesn't use a formal language, it consists of "what to
do with this piece of code" instructions. Understanding these
instructions requires knowledge and understanding of the reference
machine code patterns, instructions and system libraries.
This makes the spec not so useful for quick lookups or for
understanding what those language features are for.
It would enhance the usefulness of this important asset -the spec-
if each section would start with one or two informal paragraphs
on the most salient points of each feature.
The formal parts would still be there to confirm the details, to guide
implementers, and as the normative part of the spec. But the informal
parts would make quick lookups succeed, would give guidance on
what is being formalized, and would support program construction
("what is this good for?" rather than just "how do I implement this?").
More information about the es-discuss