Existential operator (was: ||= is much needed?)

[Aymeric Vitte]

Complement for my last sentence : if you are using ?. it means that you 
don't know if the thing does exist, then you are probably waiting for it 
to exist (asynchronous environments for example), then once you get it, 
it is very unlikely that you call it right away, I would like to see 
some examples

Le 20/06/2012 00:36, Aymeric Vitte a écrit :
> Coffeescript seems to have some radical behavior (a.b?.c.d.e.f) a bit 
> similar to what I suggested (which ok can not be in js)
>
> But the discussion here still does not say how much a.b?() or 
> a.b?.call(xxx) is used in coffeescript
>
> Personnaly I was thinking that ?. should more allow to check existence 
> rather than both checking and calling it if it exists, difficult to 
> win everywhere
>
> Le 19/06/2012 22:35, Allen Wirfs-Brock a écrit :
>>
>> On Jun 19, 2012, at 12:37 PM, Jeremy Ashkenas wrote:
>>
>>> On Tue, Jun 19, 2012 at 3:33 PM, Allen Wirfs-Brock 
>>> <allen at wirfs-brock.com <mailto:allen at wirfs-brock.com>> wrote:
>>>
>>>
>>>     >  foo.bar?(args) <==>  foo.bar?.call(foo, args)
>>>     >  fun?(args) <==>  fun?.call(undefined, args)
>>>
>>>     How are these equivalent? Won't  fun?.call evaluate to undefined
>>>     if fun is undefined and undefined(undefined,args) will throw...
>>>
>>>
>>>  ... check out the compilation:
>>>
>>> http://coffeescript.org/#try:fun%3F.call(undefined%2C%20args)%0A%0Awindow.method%3F.call(window%2C%20args) 
>>> <http://coffeescript.org/#try:fun?.call%28undefined,%20args%29%0A%0Awindow.method?.call%28window,%20args%29>
>>
>> Ah, interesting...so this is actually close to what I was advocating 
>> for this particular case.  However, if I now understand correctly you 
>> are saying that
>>      fun?.call()
>> produces undefined if fun is null/undefined but will throw if fun is 
>> defined as:
>>    fun = new Object;
>> because it doesn't have have "call" property.
>>
>> Also, it isn't clear to me why the second example 
>> (window.method?.call(window, args))  is only guarding for null and 
>> not undefined.  Is it only because you guard for undefined on 
>> variable references and not on property references?
>>
>> Basically, I see what the code you generate is doing but the unlying 
>> semantics that yields that code is less obvious.
>>
>>>
>>> It doesn't eagerly evaluate to undefined ... the value of the 
>>> *entire* expression is undefined if the chain is broken at the 
>>> existential operator. That's much of the point of soaks:
>>>
>>> object.property?.i.can.keep.chaining.in.here.without.throwing.errors.if.property.is.undefined 
>>>  ;)
>>
>> Ah, again.  I don't think Brendan's strawman will produce that 
>> result.  The ...?.i is going to get undefined when it does GetValue 
>> on the Reference produced for object.property.  Then undefined.can 
>> will throw in step 5 of 11.2.1 because the LHS is undefined.  Getting 
>> this behavior seems to requires modifying . as well as defining ?.
>>
>> Allen
>>
>>
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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/20120620/fa7f2826/attachment.html>