More fun with undefined

Aymeric Vitte vitteaymeric at gmail.com
Fri Jun 15 06:34:16 PDT 2012


Probably there are very good reasons but I reask the question : why 
should the attempt to access a property of a variable equal to undefined 
global property not return undefined global property ? (ie a way that 
this works : if (a.b.c.d) {} when a,a.b, etc are not set)

This can be usefull when things get loaded asynchronously and then when 
you don't know when it will be available (it does not happen every day, 
but in some cases you don't have necessarily a callback or an event to 
tell you and then asynchronous stuff can start being extremely difficult 
to handle).

Example :

console.log(a);//Reference error, GetBase returns undefined

console.log(window.a);//undefined

--> does not seem very logical, no ?

Maybe it was discussed thousand of times, but why not :

8.9.1 GetValue (V)
...
5. If IsUnresolvableReference(V), return undefined

Le 15/06/2012 01:22, Allen Wirfs-Brock a écrit :
>
> On Jun 14, 2012, at 3:49 PM, Rick Waldron wrote:
>
>>
>>
>> On Thu, Jun 14, 2012 at 5:35 PM, Thaddee Tyl <thaddee.tyl at gmail.com 
>> <mailto:thaddee.tyl at gmail.com>> wrote:
>>
>>     On Thu, Jun 14, 2012 at 3:29 PM, Allen Wirfs-Brock
>>     <allen at wirfs-brock.com <mailto:allen at wirfs-brock.com>> wrote:
>>     > This is a different issue, but I wonder how badly the web would
>>     break if we
>>     > made undefined a reserved word.  Does anybody in JS really
>>     declare a
>>     > different local binding for undefined?  In ES5 we got away with
>>     making
>>     > undefined read-only.  Maybe we should continue pushing and see
>>     if we can
>>     > eliminate the rebindable undefined hazard.
>>
>>     JQuery [1] famously has an "undefined" parameter, like so:
>>
>>        (function( window, undefined ) { ... }(window))
>>
>>
>>
>> Actually, this exists because undefined wasn't reserved. We would 
>> certainly remove the formal param in favor of an reserved undefined. 
>> Unfortunately, we can't "take it back" in extant code.
>
> A wonder if this wart is hairy enough, that we wouldn't be justified 
> in some explicit backwards compatibility hackery in the spec. to 
> remove it.
>
> For example, we could allow it to appear in parameter lists and 
> provide a dynamic check to ensure that nothing (other than a real 
> undefined) is passed.  Similarly we could explicitly allow:
>       var undefined;
>
> Certainly there is no particular reasons we need to allow:
>   let undefined;
>   const undefined=true;
>   class undefined extends foo { }
> or any other new binding forms redefining undefined.
>
> Allen
>
>
>
>
>
>
>
>
>>
>>
>> Rick
>>
>>
>>
>>     What would happen in this case?
>>
>>      [1] http://code.jquery.com/jquery-1.7.2.js
>>     _______________________________________________
>>     es-discuss mailing list
>>     es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>>     https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-- 
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/c655d179/attachment.html>


More information about the es-discuss mailing list