On Wed, Jul 7, 2010 at 11:51 PM, Brendan Eich <brendan at mozilla.org> wrote:
> Yeah, good for strict mode. What about the arrant conflict betwen ES1-3 and
> ES5 non-strict?
>> More significantly, a FunctionDeclaration was the one guaranteed binding
> form in ES1-3. Now it may or may not bind the declared property. That seems
> like a loss to me.
>
Ok, I think I'm beginning to see the issue. However, I don't see any way to
change the spec to accommodate this issue that would be simple enough to
count as an errata.
If we're willing to admit larger changes, then we'd need to separate
initializing a FunctionDeclaration F from assigning to F, so that the first
can be defined in terms of [[DefineOwnProperty]] while the latter remains
defined in terms of [[Put]]. The revised Environment Record structure
proposed for Harmony at <
http://wiki.ecmascript.org/doku.php?id=harmony:block_scoped_bindings>
already has the right degrees of freedom. The additional change we'd need to
make is in 10.5 Declaration Binding Instantiation step 5.e where we'd change
function initialization to use InitializeBinding rather than
SetMutableBinding.
Although this is a bigger change to the spec language of ES5, it does not
make ES5 any less internally consistent, does not split strict vs non-strict
on this issue, and actually makes ES-next *more* consistent. In ES-next, all
block scoped declarations --- let, const, and function --- would all be
initialized by [[DefineOwnProperty]] without calling setters.
An initialization would still fail when it should, but a blocked scoped
initialization would never call a setter. An assignment still would. The odd
man page out would then be "var" declarations, because they would continue
to have assignment rather than initialization semantics. This seems a good
compromise.
But are we willing to consider an "errata" that substantial? Is there any
less invasive way to handle this issue?
--
Cheers,
--MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es5-discuss/attachments/20100708/33025021/attachment-0001.html>