> Mark Miller worked on E and then on Google's Caja (stands for 'Capability JavaScript'). He has been leading an effort to port features from Caja into ES via the 'Secure ECMAScript' initiative:
https://github.com/drsesSo nothing to do with current ES, and if anything a dead effort, the "Secure ECMAScript" repository hasn't seen an update in 5 years.
> Doug Crockford worked on E and ported E's data mini-language, TermL, to JS and it became JSON.
Do you have any evidence for those assertions as explanations, rather than the rather obvious and much simpler "he was looking for a data format to communicate between frontend and backend and javascript literals could be trivially and quickly eval'd from the client"?
> The json.org website still links into the E archeological site from its front page: http://erights.org/data/terml/embeddings.html
Insultingly misleading. json.org links to that page from a section on json implementations in various languages, because that page has a section on "json in terml". In fact, that's the exact label of the link on json.or. It also links to pages for labview, M or PascalScript, that doesn't mean JSON traces its roots to any of those.
> The WeakMap feature of ES doesn't mention it in the spec [0] but the 'sealer/unsealer' capability pattern can be implemented on top easily
You can implement stuff on top of existing features, news at 11.
> and in fact having WeakMap is equivalent to having E's brand-maker or Monte's makeBrandPair
Of course WeakMap is also and more directly equivalent to having weak maps from dozens of preceding language.
Your comment distinctly looks like you're just seeing everything through the E lens because you really want it to be relevant, and hammering the ES peg in the E hole no matter how the fit is.
So nothing to do with current ES, and if anything a dead effort, the "Secure ECMAScript" repository hasn't seen an update in 5 years.
> Doug Crockford worked on E and ported E's data mini-language, TermL, to JS and it became JSON.
Do you have any evidence for those assertions as explanations, rather than the rather obvious and much simpler "he was looking for a data format to communicate between frontend and backend and javascript literals could be trivially and quickly eval'd from the client"?
> The json.org website still links into the E archeological site from its front page: http://erights.org/data/terml/embeddings.html
Insultingly misleading. json.org links to that page from a section on json implementations in various languages, because that page has a section on "json in terml". In fact, that's the exact label of the link on json.or. It also links to pages for labview, M or PascalScript, that doesn't mean JSON traces its roots to any of those.
> The WeakMap feature of ES doesn't mention it in the spec [0] but the 'sealer/unsealer' capability pattern can be implemented on top easily
You can implement stuff on top of existing features, news at 11.
> and in fact having WeakMap is equivalent to having E's brand-maker or Monte's makeBrandPair
Of course WeakMap is also and more directly equivalent to having weak maps from dozens of preceding language.
Your comment distinctly looks like you're just seeing everything through the E lens because you really want it to be relevant, and hammering the ES peg in the E hole no matter how the fit is.