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
<al...@wirfs-brock.com <mailto:al...@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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
jCore
Email :avi...@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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
jCore
Email : avi...@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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
