We've found the need for serializable functions in AmbientTalk, which,
like JS, encourages a style of programming that makes significant use
of lexical nesting. We have found that this programming style makes
that requiring serializable functions to be closed is indeed too
Tom Van Cutsem wrote:
var f = function(x,y) (z) {
Tiny bike-shed-ish comment that we need a linking punctuator so that
arrow function syntax can be extended likewise:
var f = function (x, y) : (z) {...}
Arrow form showing expression body:
var f = (x, y) : (z) = x*y/z;
An alternative
Tiny bike-shed-ish comment that we need a linking punctuator so that
arrow function syntax can be extended likewise:
var f = function (x, y) : (z) {...}
Arrow form showing expression body:
var f = (x, y) : (z) = x*y/z;
FWIW, I like the semi colon. However, I prefer
|
Maybe, but:
(1) annotations are user-hostile even in a language like Rust, wherefore
type-and-lifetime inference, which you are not proposing.
(2) we need a sane default, if not inference.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
Le 26/09/2013 15:36, Bradley Meck a écrit :
The only really think of that would be of benefit is parallel execution.
MongoDB MapReduce exploits parallelism as much as one can ever hope and
just a string generated from
var f = '' + function(){...}
seems to work just fine.
(this actually
It's unclear what your threat model is. What do you want to defend, from
who or what, and for how long?
On 26 Sep 2013 00:40, Aymeric Vitte vitteayme...@gmail.com wrote:
This is similar to the Native thread as Andrea mentioned.
Then when SES is coming?
It seems urgent to boost it, I have
I would like to defend against a potential mitm/code injection and
ideally against globals modifications.
Unfortunately I have the ws problem which screw up a little bit the use
case. So, we have the scenario that you see at the begining of [1],
forget about the unsafe-inline, I thought it
On Thu, Sep 26, 2013 at 9:56 AM, Aymeric Vitte vitteayme...@gmail.comwrote:
I would like to defend against a potential mitm/code injection and
ideally against globals modifications.
Only one of those is a threat (MITM). The other is an effect of something
happening (which you may or may not
Le 26/09/2013 20:14, Alex Russell a écrit :
On Thu, Sep 26, 2013 at 9:56 AM, Aymeric Vitte vitteayme...@gmail.com
mailto:vitteayme...@gmail.com wrote:
I would like to defend against a potential mitm/code injection and
ideally against globals modifications.
Only one of those is a
similar thread proposing 'use native' for the very similar problem safe
closures would like to solve ... I wonder if it wouldn't be good enough to
retrieve in a read-only fashion all original exposed function prototypes
through a constant or read-only global property for the current realm ...
Hi François, your goals here have a tremendous overlap with SES. In what
ways is SES not satisfactory for these purposes?
The best short-but-accurate summary of SES, sufficient for this question,
is http://research.google.com/pubs/pub40673.html section 2.3.
SES does not remove eval and Function,
On Wed, Sep 25, 2013 at 5:32 PM, Mark S. Miller erig...@google.com wrote:
Hi François, your goals here have a tremendous overlap with SES. In what
ways is SES not satisfactory for these purposes?
The best short-but-accurate summary of SES, sufficient for this question,
is
Sorry* *François,
I didn't mean to say your goals were those but I see your problem as safe
evaluation over a must be safe sort of local environment confined closure
per closure which is actually similar to the 'use native' directive
proposed in the other thread.
My idea is that functions can
A concrete example of using SES to serialize and unserialize safe closure
free functions is Bob, serializing the escrowExchange function on line 22
of
https://code.google.com/p/es-lab/source/browse/trunk/src/ses/contract/makeBob.js#22
:
var escrowSrc = ''+escrowExchange;
This works because
14 matches
Mail list logo
