More fun with undefined

[Aymeric Vitte]

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 <vitteaymeric at gmail.com 
> <mailto:vitteaymeric at gmail.com>> 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 :  avitte at jcore.fr
Web :    www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120615/4f1efae3/attachment.html>