Mike Samuel wrote: > 2009/12/8 David-Sarah Hopwood <[email protected]>: >> var f = /*...@functional*/ function (evil, s) { >> evil(s); >> }; >> >> f is now copacetic. >> >>> If passed the arguments (freeze(eval), 'a = 0') it will modify the >>> lexical environment, and I think both arguments are copacetic >>> according to the frozen functions definition, >> In >> >> f(cajita.freeze(eval), 'a = 0;'); >> >> there is a free variable reference 'eval', and the global eval is >> not accessible to Cajita code. So this program is not valid Cajita. > > So it is not a goal for a copacetic program to maintain its properties > when functions defined in it are called by non-strict non-cajita code. > So it is the copacetic program parsers responsibility to make sure > that such functions do not escape to where they could be called that > way?
Non-Cajita ECMAScript code would not be able to mutate copacetic values, because copacetic would imply deep-frozen using ES5 Object.freeze. Also, non-global eval can only mutate variables in the lexical scope in which 'eval' is referenced. So non-Cajita code could only manipulate its own scope this way, not Cajita scopes. This assumes that non-Cajita code can't diddle with the copacetic marker tags, or otherwise interfere with the security of the Cajita runtime. Note that any implementation of a marker tag using a property on the marked object would not work here, because non-Cajita code would be able to set that property on a new object in the same way (and with the same attributes) as the Cajita runtime. However, a Name or Trademark mechanism (which can be implemented in terms of weak hashtables), could work. See <http://wiki.ecmascript.org/doku.php?id=strawman:weak_references>, subsection 'Trademarking', for instance. -- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
