Right now I am not proposing but trying to understand why it is like
this (and why on some aspects it is strange), and if by any chance
a.b.c.d could be solved. Indeed this would require an early return from
Accessors too after GetValue(base) . I don't understand why you focus on
global var being created, this is not the case.
Maybe I am misreading something in the chain, the Accessors
CheckObjectCoercible and GetValue IsUnresolvableReference look to be
redundant in this case.
var a;
console.log(a.b); //TypeError for you (correct ?)- Reference error for me
console.log(c.d);//Reference error for me
Le 15/06/2012 16:56, T.J. Crowder a écrit :
On 15 June 2012 15:34, Aymeric Vitte <[email protected]
<mailto:[email protected]>> wrote:
I am not talking about defining implicit properties or such
things, neither having undeclared stuff looking declared, but just
changing the behavior of retrieving a property when base is
undefined, which will then be undefined.
If am I reading correctly the specs, doing this change will work
for a.b.c.d, because undefined is returned first and nothing is
set anywhere, unless I am wrong :
console.log(a); //reference error
var a;//undefined
console.log(a.b);//reference error
will become :
console.log(a); //undefined
var a;//undefined
console.log(a.b);//undefined
So you're proposing two changes:
1. Let getting an unresolvable symbol evaluate to `undefined`, rather
than causing a ReferenceError (which requires changing GetValue, at
least), and
2. Allow accessing a property of `undefined` to evaluate to
`undefined`, rather than causing a TypeError (which requires changing
either how property accessors work, or changing the definition of
CheckObjectCoercible so that it coerces undefined into {} or some such).
You'd need both of them to make `a.b` "work" (evaluate to undefined
rather than throwing) where `a` is unresolvable, #1 to prevent the
ReferenceError on `a`, and #2 to prevent the TypeError when trying to
retrieve `b` from `undefined`.
Either would be a big, breaking change on its own.
Re #1: I wouldn't be in favor, FWIW. I think it's much better to have
a ReferenceError on an unresolvable symbol than have it treated as
though it were resolved, but had the value `undefined`. Again, the
feature of strict mode where assigning to unresolvable symbols stopped
creating global variables was a Good Thing(tm). :-) To me this is in
the same vein as the old behavior there was. If I try to read the
value of an unresolvable symbol, I want the proactive notification I
get from the ReferenceError; I don't want to try to find the subtle
bug the implicit `undefined` helps hide (in my view).
Re #2: I wouldn't be in favor, FWIW. Consider:
function foo(o) {
console.log(o.msg);
}
foo();
Currently, the call to `foo` throws, because I'm not passing in any
argument, but the code dereferences `o` without testing first. This is
clearly a bug in the call to `foo`. Currently, I get proactive
notification of that bug (via the TypeError). With change #2, the code
would try to log undefined instead -- a much harder, more subtle bug
to try to find and fix.
Yes, the current behavior wrt reading from unresolvable references vs.
reading from undefined properties can be viewed, from some angles, as
inconsistent. But it's very thoroughly ingrained in the language, and
I don't see a strong argument for change.
Just my $0.02.
Best,
-- T.J.
--
jCore
Email : [email protected]
Web : www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
