On Sep 2, 2011, at 3:01 PM, Bradley Meck wrote: > Even worse, libraries must support this, similar to > how a few libraries that break when a script in strict mode invokes > them but unlike frowned upon features,
Strict mode is a static property of code. Strict callers cannot affect behavior of non-strict callees. So I'm not sure what you mean here. Can you give an example? > we are talking about every > feature that a proxy has would have to be guarded for this. In the browser, DOM and host object precedent means we crossed this bridge a long time ago. IINM, Node has built-in objects that can do magical host-object-like things too. Has it therefore crossed the same bridge too? That is, couldn't such Node host objects be passed to library code that cannot assume plain-old-native-object non-magical semantics? > Monads through callbacks instead of hiding async behavior through > proxies is a better idea not just because of the complex compilation Ok, my b.s. detector is going off. You used "actors" in the first para about Node, but Node is JS and JS (or Mikeal's favorite subset used in Node built-in and approved libraries) is not an Actor language. "Monads" here sounds impressive but JS has mutation and dynamic types, so what do you really mean? Finally, proxies do not affect execution model at all, so whether a promise uses proxies for "catch-all" get and set interception, or forsakes proxies in favor of method calls, is not material. > changes needed to support this, but also because a user of an API can > expect for something to have an unknown return time with callbacks. Proxies do not introduce hidden preemption points with attendant data race hazards. At all. Why did you think they could? /be _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
