Re: Template strings as a template language.

thon's. > > On 13 September 2015 at 15:15, Mark S. Miller wrote: > >> >> >> On Sun, Sep 13, 2015 at 7:08 AM, Thomas >> wrote: >> >>> What I've been doing: >>> >>> export const template = ({title, content}) => `templa

Re: Template strings as a template language.

still put something inside a template > string and do nasty stuff, but I'm not sure if that's a easily solved > problem. > > On 13 Sep 2015, at 10:08 PM, Mark S. Miller wrote: > > On Sun, Sep 13, 2015 at 2:42 AM, Thomas > wrote: > >> I'd really like to us

Re: Template strings as a template language.

On Sun, Sep 13, 2015 at 2:42 AM, Thomas wrote: > I'd really like to use Template strings as a templating language, but > unless I include a lot of boilerplate code (export a template string > wrapped in a function from a file) Hi Thomas, could you give a concrete example of the boilerplate you

Re: Object id, hash, etc?

Hi Tab, then you get the Labeler, which this message is responding to. On Tue, Sep 8, 2015 at 2:12 PM, Tab Atkins Jr. wrote: > On Tue, Sep 8, 2015 at 2:07 PM, Mark S. Miller wrote: > > On Tue, Sep 8, 2015 at 1:57 PM, Michael McGlothlin > > wrote: > >> > >> I t

Re: Object id, hash, etc?

; this[ identity ] = ++OBJECT_ID; > Does not work on frozen objects. >} > return this[ identity ]; > } > } ); > > On Tue, Sep 8, 2015 at 1:44 PM, Mark S. Miller wrote: > >> See Labeler at >> http://wiki.ecmascript.org/doku.php?id=harmony:weak

Re: Object id, hash, etc?

See Labeler at http://wiki.ecmascript.org/doku.php?id=harmony:weak_maps#unique_labeler On Tue, Sep 8, 2015 at 11:16 AM, joe wrote: > Didn't send to list, something is wrong with my reply all. Sorry about > that. Stupid mobile gmail. > -- Forwarded message -- > From: "joe" > Da

Re: Weak References

gt; language, so weak references are the best way to avoid this. And if I were > doing this in Java or C++, I would most definitely use weak > references/pointers for this use case. (This is out of the land of what > automatic garbage collection can handle at this point.) > > On Mon,

Re: Weak References

I also don't get the purpose of this code. What is it trying to achieve? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Weak References

l(function () { > > try { > > setStream(stream.get(), format) > > } catch (e) { > > // reference is dead, clear this timer > > clearInterval(this) > > > > // break strong reference to weak

Re: Weak References

On Sun, Sep 6, 2015 at 8:04 PM, Isiah Meadows wrote: > My original email featured a use case, although I had to rewrite it to use > explicit garbage collection. I need a way to watch for when the object is > garbage collected. > > ```js > [...Somehow reformatted in transit...] > ``` > Hi Isiah

Re: Weak References

On Sun, Sep 6, 2015 at 10:32 AM, Isiah Meadows wrote: > That's actually the feature I need... > Hi Isiah and Thomas, what "That"? If you mean pre-mortem finalization, like Java's Object.finalize or the cited node callbacks (whose pre-mortem nature is made clear by isNearDeath at < https://github.

Re: Weak References

On Sun, Sep 6, 2015 at 3:37 AM, Gary Guo wrote: > I think weak references are discussed before, and get postponed because it > can cause information leaks between realms. > http://wiki.ecmascript.org/doku.php?id=strawman:weak_refs#security says To plug this leak, a weak reference created within

Re: Weak References

On Sat, Sep 5, 2015 at 4:07 AM, Isiah Meadows wrote: [...] Thankfully, I'm using Node.js, so `weak` [2] is an option (the only option, > really). But I would definitely appreciate if it was available in JS > proper, across engines. V8, SpiderMonkey, and JSC all have weak references > to JS objec

Re: Weak References

On Sat, Sep 5, 2015 at 4:07 AM, Isiah Meadows wrote: > I'm resurrecting this [1] because I have found a use case where I needed a > weak reference. Is there any chance this could get into the language? > I wrote the [1] strawman and continue to be positive on the idea. The strawman text is old a

Re: Exponentiation operator precedence

On Wed, Aug 26, 2015 at 6:19 PM, Waldemar Horwat wrote: > On 08/26/2015 15:08, Mark S. Miller wrote: > >> The force of that precedent is indeed what my objection is. The "yield" >> counter-example is interesting, but "yield" is an identifier not an >>

Re: Assignment of global variables deleted by their RHS in strict mode

On Wed, Aug 26, 2015 at 2:55 PM, Kevin Gibbons wrote: > See the following test262 test: > https://github.com/tc39/test262/blob/master/test/language/expressions/assignment/S11.13.1_A5_T5.js > (and related tests with update / compound assignment). > > In short, it is possible to have a Reference to

Re: Exponentiation operator precedence

On Wed, Aug 26, 2015 at 2:55 PM, Waldemar Horwat wrote: > On 08/26/2015 09:09, Mark S. Miller wrote: > >> I don't get it. The conflict between >> >> * the history of ** in other languages, >> * the general pattern that unary binds tighter than binary >> &

Re: Exponentiation operator precedence

t, no one is confused by either -Math.pow(2, 2) or Math.pow(-2, 2). On Wed, Aug 26, 2015 at 9:00 AM, Jason Orendorff wrote: > On Tue, Aug 25, 2015 at 5:43 PM, Mark S. Miller > wrote: > > When the costs were minor, it was ok that the benefits were minor. > > The costs will pro

Re: Exponentiation operator precedence

I completely agree. My "When the costs were minor" refers to when we were not yet aware of the conflict. On Wed, Aug 26, 2015 at 12:19 AM, Claude Pache wrote: > > Le 26 août 2015 à 00:43, Mark S. Miller a écrit : > > When the costs were minor, it was ok that the bene

Re: Exponentiation operator precedence

When the costs were minor, it was ok that the benefits were minor. Given significant costs, we need to ask: Why do we need ** ? What great benefit does it provide? If nothing compelling, then this proposal has lost consensus. On Tue, Aug 25, 2015 at 3:30 PM, Claude Pache wrote: > > > Le 25 ao

Re: Exponentiation operator precedence

Sorry. I just has another look at your proposed grammar and you are correct. On Tue, Aug 25, 2015 at 10:54 AM, Claude Pache wrote: > > Le 25 août 2015 à 19:25, Mark S. Miller a écrit : > > It also does not work. x ** y ** z, if we allow it at all, must be right > associative. I

Re: Exponentiation operator precedence

It also does not work. x ** y ** z, if we allow it at all, must be right associative. It must parse as x ** (y ** z). On Tue, Aug 25, 2015 at 10:08 AM, Mark S. Miller wrote: > It does not work as well as simply omitting ** entirely. > > > On Tue, Aug 25, 2015 at 9:42 AM, Isiah Mead

Re: Exponentiation operator precedence

It does not work as well as simply omitting ** entirely. On Tue, Aug 25, 2015 at 9:42 AM, Isiah Meadows wrote: > I like this. It works very well. > > On Tue, Aug 25, 2015, 12:38 Claude Pache wrote: > >> >> I think the following grammar could work. >> Replace the current (ES2015) PostfixExpress

Re: Exponentiation operator precedence

I think we should drop the feature. Given the conflict between * the history of ** in other languages, * the general pattern that unary binds tighter than binary any solution at this point will confuse many people. These confusions will not result in a confusing static rejection but in runtime be

Re: standardizing Error.stack or equivalent

On Thu, Mar 27, 2014 at 3:28 PM, Mark S. Miller wrote: > [+google-caja-discuss] > > Cool. I will fix the debug.js adaptor > a) to fix the bug Boris reported, > b) to map the FF nested format to the v8 nested format, and > c) to preserve this information from the v8 API

Re: await on synchronous functions

On Sun, Jul 19, 2015 at 10:16 AM, Bergi wrote: > Mark S. Miller wrote: > > We've talked about allowing await at the top level of modules, I think so >> that the await continuation could proceed after the synchronous part of >> the >> load. I am unclear on the

Re: await on synchronous functions

On Fri, Jul 17, 2015 at 3:06 PM, Alexander Jones wrote: > Changing a function from returning a Promise to returning a T is just > the same as changing it to return any other type. > This sounds like the old monad vs promise debate. EcmaScript promises have already decided against the monad camp.

Re: await on synchronous functions

On Fri, Jul 17, 2015 at 12:57 PM, Ben Newman wrote: > Yep, all current implementations that I know of (Traceur, > Babel/Regenerator, various other generator-based approaches) do what you > want, because Promise.resolve(fn()).then(result => ...) always runs the > callback a future turn of the even

Re: await on synchronous functions

On Fri, Jul 17, 2015 at 12:50 PM, Mark Volkmann wrote: > Going back to my original question, suppose I write this: > > for (let fn of myFunctions) { > let result = await fn(); > // Do something with result. > } > > If all the functions happen to be synchronous and take a while to > complete,

Re: await on synchronous functions

On Fri, Jul 17, 2015 at 12:44 PM, Ben Newman wrote: > Having addressed (1) earlier, perhaps by mistake, my thought on (2) is > that you probably want await f() to work the same way if f() just happens > to return a Promise, as when f is actually async, but there is no way to > know, in general, i

Re: await on synchronous functions

I would expect any implementation to do #2 since that's what the draft spec says. On Fri, Jul 17, 2015 at 12:40 PM, Mark Volkmann wrote: > Yes, I am asking about case #2. Thanks for clarifying Chris. > For what it's worth, Traceur allows this now. > > On Fri, Jul 17, 2015 at 2:36 PM, Chris Tosh

Re: await on synchronous functions

On Fri, Jul 17, 2015 at 12:30 PM, Ben Newman wrote: > If we stick with the rule that await is only regarded as a keyword if it > appears in the body of an async function, then await x without async is > simply a syntax error, and we can avoid having to answer this question! > Two more possible c

Re: await on synchronous functions

Hi Andrea, what do you mean by "Promise must Promise"? I've never seen this phrase before. On Fri, Jul 17, 2015 at 11:35 AM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > > Think about a large program where you refactor a single async function > to no longer be async > > did that eve

Re: await on synchronous functions

On Fri, Jul 17, 2015 at 10:41 AM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > If I might, if there's one thing that has never particularly shone in JS, > that is consistency. > > I see only two possibilities here: 1) it throws with non Promises 2) it > "Promisify" anything that's not

Re: await on synchronous functions

On Fri, Jul 17, 2015 at 10:33 AM, Kevin Smith wrote: > I know the spec for this isn't finalized, but what is the current >> direction for the behaviour when await is used on a function that is not >> marked async and doesn't return a Promise? Should it run immediately or >> wait for the next turn

Re: await on synchronous functions

Wait for the next turn/job or the event loop. On Fri, Jul 17, 2015 at 10:09 AM, Mark Volkmann wrote: > I know the spec for this isn't finalized, but what is the current > direction for the behaviour when await is used on a function that is not > marked async and doesn't return a Promise? Should

Re: Generalize do-expressions to statements in general?

gt; On 16 July 2015 at 17:29, Mark S. Miller wrote: > >> When simply generating simple JS code from something else, this >> restriction is a perpetual but minor annoyance. >> > > Indeed, one motivation for do-expressions is better support for compilers > targeting JS. A

Re: Generalize do-expressions to statements in general?

I echo this. E is a dynamic language with many similarities with JS, including a similarly C-like syntax. In E I use everything-is-a-pattern-or-expression all the time. When I first moved to JS I missed it. Now that I am used to the JS statements-are-not-expressions restrictions, I no longer do, wi

Re: Generalize do-expressions to statements in general?

On Tue, Jul 14, 2015 at 10:59 AM, Andreas Rossberg wrote: > On 14 July 2015 at 16:48, Mark S. Miller wrote: > >> On Tue, Jul 14, 2015 at 2:31 AM, Andreas Rossberg >> wrote: >> >>> I don't see why you need parens at all, see my previous post. But I >&g

Re: Generalize do-expressions to statements in general?

age design was already conceived right by the early '70s. Retrofitting without breaking things takes much longer than invention ;) > > /Andreas > > > On 14 July 2015 at 01:33, Mark S. Miller wrote: > >> Interesting. Got me thinking. Here's an alternate proposal

Re: Generalize do-expressions to statements in general?

Interesting. Got me thinking. Here's an alternate proposal I'll call "do expressions without the 'do'." At < https://people.mozilla.org/~jorendorff/es6-draft.html#sec-expression-statement> we have the syntax of the expression statement. Ignoring sloppy "let" nonsense, this says that an expression

Re: RegExp.escape()

Safety over readability please. If there is a single fully escaped form that is safe to use in all the expected contexts, let's choose that. The results of RegExp.escape are not very readable anyway, and rarely read. So compromising safety for some contexts in exchange for incremental readability i

Re: Awaiting thenables

Y -- Cheers, MarkM On Jun 26, 2015 2:07 PM, "Jordan Harband" wrote: > so, in other words, `await thenable` would wrap the thenable in > `Promise.resolve`, which would ensure it fires on the next tick? > > On Fri, Jun 26, 2015 at 12:36 PM, Mark S. Miller >

Re: Awaiting thenables

It would be postponed to a later job, i.e., turn of the event loop. -- Cheers, MarkM On Jun 26, 2015 11:49 AM, "Francisco Tolmasky" wrote: > Apologies, I’m aware the last example didn’t make sense. What I meant was > more along the lines of the following: > > setImmediateOrOtherNextRunLoop

Re: function.sent beta equivalence?

I only sent three messages in this thread before this one. The first was completely blank, which was only a premature hitting of send, so only two real messages. On Wed, Jun 24, 2015 at 4:42 PM, Brendan Eich wrote: > Jason Orendorff wrote: > >> What does "wrap" look like? It seems like it would

Re: function.sent beta equivalence?

On Wed, Jun 24, 2015 at 3:17 PM, Mark S. Miller wrote: > > >>> Jason Orendorff wrote: >>> >>>> Quick question about function.sent: >>>> >>>> As of ES6, there's this parallel between functions and generators: >>>>

Re: function.sent beta equivalence?

> >> Jason Orendorff wrote: >> >>> Quick question about function.sent: >>> >>> As of ES6, there's this parallel between functions and generators: >>> >>> // how to wrap a function >>> // f2 is equivalent to f, if f doesn't use `this`. >>> function f(...) { ... } >>> function f2(

Re: function.sent beta equivalence?

On Wed, Jun 24, 2015 at 2:17 PM, Brendan Eich wrote: > Hrm, the meeting notes don't quite capture it ( > https://github.com/tc39/tc39-notes/blob/bf5190257d22d1c700e203b28edc8d85ee3aadcc/es6/2015-05/may-27.md > is one view; my fault for not editing after), but we have discussed passing > function.

Re: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

ication so failures in this area are clearly bugs in either > the implementation or the specification. I would suggest for JS that this > list include the things required for confining a piece of JS code running > within a larger environment, like a web page to keep it from doing all the &

Re: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

Someone just brought to my attention. It says: I like the author’s remarks and philosophy about keeping JavaScript small, but I thought the opening was remarkably uncharitable. The specific person and the specific feature are quite irrelevant to the p

Re: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

"use strict" was only a breaking change regarding ES3 code that coincidentally happened to use exactly this literal string as a do-nothing expression statement in exactly this position. In all of the web, we have not run across a single incident of this happening accidentally. For the record, not

Re: Re: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

On Fri, Jun 19, 2015 at 12:29 PM, Alex Russell wrote: > I do not share Mark's view. Contra his sentiment, I was using the "small" > version of JS for many years and noted that most non-trivial uses required > finding or building a library. That choice of library (which exist to fill > in platfor

The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

On Wed, Jun 17, 2015 at 7:27 PM, Kyle Simpson wrote: > I'd like to ask if there's anyone on TC39 that would be willing to > champion a proposal to add the let-block (let-statement) syntax? > I am not. Further, if anyone were, I would work to kill it. Here's why. The Algol, Smalltalk, Pascal, a

Re: Template site objects and WeakMap

lease let's not. On Wed, Jun 17, 2015 at 1:51 PM, Allen Wirfs-Brock wrote: > > On Jun 17, 2015, at 9:18 AM, Mark S. Miller wrote: > > > [+Allen] > > > > Can registered Symbols be used as keys in WeakMaps? If so, we have a > fatal unauthorized communications

Re: Re: Template site objects and WeakMap

The idea that (a shared Weak interning table of immutable-objects-with-identity + WeakMaps makes gc observable) is not new. The idea that (the shared interning tables of immutable-objects-with-identity must therefore be strong) is not new. What was new to me is the idea that Interning of a pa

Re: Template site objects and WeakMap

> just FYI > > > On Jun 17, 2015, at 2:49 PM, Boris Zbarsky wrote: > > > > On 6/17/15 2:35 PM, Mark S. Miller wrote: > >> What do other browsers currently do? > > > > Firefox: > > > > > var w = new WeakMap(); var r = Symbol.for

Re: Template site objects and WeakMap

On Wed, Jun 17, 2015 at 11:19 AM, Yusuke SUZUKI wrote: > It turns out the spec is fine < >> https://people.mozilla.org/~jorendorff/es6-draft.html#sec-weakmap.prototype.set> >> step 5 says >> >> If Type >>

Re: Template site objects and WeakMap

On Wed, Jun 17, 2015 at 9:31 AM, Yusuke SUZUKI wrote: > On Thu, Jun 18, 2015 at 1:18 AM, Mark S. Miller > wrote: > >> [+Allen] >> >> Can registered Symbols be used as keys in WeakMaps? If so, we have a >> fatal unauthorized communications channel that w

Re: Template site objects and WeakMap

[+Allen] Can registered Symbols be used as keys in WeakMaps? If so, we have a fatal unauthorized communications channel that we need to fix in the spec asap! ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Template site objects and WeakMap

sing weak references > to the callsites would, in the majority of cases, mean recreating them > every time they were used. So, while making the implementation more > complicated, I don’t think it would be a win for performance, only for > memory consumption. > > > On Jun 16, 201

Re: Template site objects and WeakMap

ailable at parse-time when the hashing occurs), there’s no > way to store these callsites in a WeakMap, and they are never collected. If > WeakSets were iterable, this could be solved pretty easily, but these are > the tools we’ve got :( > > On Jun 16, 2015, at 10:31 PM, Mark S. Mil

Re: Template site objects and WeakMap

Hi Yusuke, I am not sure I understood your message. Could you show some example code that would observe the observable difference you have in mind? On Tue, Jun 16, 2015 at 7:25 PM, Yusuke SUZUKI wrote: > Hi forks, > > In ES6 spec, template site objects are strongly referenced by the > realm.[[

Re: RegExp.escape()

On Sat, Jun 13, 2015 at 11:39 AM, Benjamin Gruenbaum wrote: > On Sat, Jun 13, 2015 at 9:07 PM, Mark S. Miller > wrote: > >> On Sat, Jun 13, 2015 at 9:17 AM, Domenic Denicola wrote: >> >>> All of these should be building on top of RegExp.escape :P >>> >

Re: RegExp.escape()

d do other than reject with an error. But what if the strings happen to be mutually valid but with conflicting meaning between these subclasses? > > > *From:* es-discuss [mailto:es-discuss-boun...@mozilla.org] *On Behalf Of *Mark > S. Miller > *Sent:* Saturday, June 13, 2015 02:39

Re: RegExp.escape()

The point of this last variant is that data gets escaped but RegExp objects do not -- allowing you to compose RegExps: re`${re1}|${re2}*|${data}` But this requires one more adjustment: > > function re(first, ...args) { > let flags = first; > function tag(template, ...subs) { > c

Re: RegExp.escape()

Perfection? function re(first, ...args) { let flags = first; function tag(template, ...subs) { const parts = []; const numSubs = subs.length; for (let i = 0; i < numSubs; i++) { parts.push(template.raw[i]); const subst = subs[i] instanceof RegExp ? subs[

Re: RegExp.escape()

Good idea bug infinite recursion bug. Fixed: function re(first, ...args) { let flags = first; function tag(template, ...subs) { const parts = []; const numSubs = subs.length; for (let i = 0; i < numSubs; i++) { parts.push(template.raw[i]); parts.push(sub

Re: RegExp.escape()

Nice! Inspired // Based on // https://github.com/benjamingr/RexExp.escape/blob/master/polyfill.js function re(template, ...subs) { const parts = []; const numSubs = subs.length; for (let i = 0; i < numSubs; i++) { parts.push(template.raw[i]); parts.push(subs[i].replac

Re: When the only tool you have is subclassing, all extensions look like....

t res, rej; > super((a,b)=>{res=a;rej=b;}); > this.handle = gensym(); > // first argument is "destination" of the operation > rpcCall(this.handle, ...args).then( v => res(v), e => rej(v) ); > } > } > ``` > --scott > ​ > > On Tue, Jun 9, 20

Re: When the only tool you have is subclassing, all extensions look like....

ral to me... > > What's the specific use case which you can't make work with a Promise > subclass? > Funny enough, I replied before I saw this. The use case I can't make work using only subclassing as an extension mechanism is promise pipelining. > --scott >

Re: When the only tool you have is subclassing, all extensions look like....

On Tue, Jun 9, 2015 at 9:13 AM, Mark S. Miller wrote: > My larger theme here is that I think promise subclassing is way overrated. > OO programmers tend to treat subclassing according to the "everything is a > hammer" rule. Promises do need an extension point, such as th

Re: PerformPromiseAll

On Tue, Jun 9, 2015 at 9:29 AM, C. Scott Ananian wrote: > Mark: The `prfun` library in fact uses `Promise#timeout(n)` instead of a > `TimeoutPromise` subclass. But this is really a language-design question. > You might as well ask why we have `WeakMap()` as a constructor instead of > using `Map#

Re: Ideas on type hinting and named parameters

gt; > > https://github.com/WebReflection/define-strict-properties#define-strict-properties > > Best Regards > > > > > > > On Tue, Jun 9, 2015 at 4:44 PM, Mark S. Miller wrote: > >> On Tue, Jun 9, 2015 at 8:30 AM, Luke Scott wrote: >> [...] &

When the only tool you have is subclassing, all extensions look like....

ats to be explained in later email.) On Tue, Jun 9, 2015 at 9:00 AM, Mark S. Miller wrote: > I know I'm being picky here, but if timeout-ness is not intended to > propagate, which seems sensible, then why would I ever want to invent a > TimeoutPromise subclass rather than using a

Re: PerformPromiseAll

I know I'm being picky here, but if timeout-ness is not intended to propagate, which seems sensible, then why would I ever want to invent a TimeoutPromise subclass rather than using a combinator like delay or race on a plain Promise? ___ es-discuss mailin

Re: Ideas on type hinting and named parameters

On Tue, Jun 9, 2015 at 8:30 AM, Luke Scott wrote: [...] > It currently uses `=` to define properties. And there is some debate > whether or not properties should be initialized in the constructor or be on > the prototype. > There is no debate about whether per-instance state (of whatever form)

Re: PerformPromiseAll

On Tue, Jun 9, 2015 at 7:58 AM, C. Scott Ananian wrote: > Mark: I outlined two of these use cases in > https://esdiscuss.org/topic/subclassing-es6-objects-with-es5-syntax#content-50 > > One is `WeakPromise` which is a promise holding a weak reference to its > resolved value. This is the closest

Re: PerformPromiseAll

It would help to have a concrete motivating example where the Promise subclass were usefully distinct from the Promise subclass' species. On Tue, Jun 9, 2015 at 7:30 AM, C. Scott Ananian wrote: > `Promise.resolve` doesn't use the species pattern any more: > https://esdiscuss.org/topic/fixing-pr

Re: Fixing `Promise.resolve()`

Hi Scott, If the change is as simple as it appears, it seems it will go into ES6 itself! Thanks for pushing this forward. On Tue, Jun 2, 2015 at 1:25 PM, C. Scott Ananian wrote: > Thanks! It looks like core-js has already patched in the new spec: > https://github.com/zloirock/core-js/issues/

Re: let function

Yes. I proposed it and plan to do so again. Likewise with const classes. In both cases, it imposes additional tamper-proofing restrictions along the lines of the StrongScript proposal in order to support writing defensively consistent abstractions. On Tue, May 19, 2015 at 3:02 PM, Kevin Smith w

Re: *.empty Idea

On Thu, Apr 30, 2015 at 12:46 PM, C. Scott Ananian wrote: > I like the idea of snapshot methods, but they can be implemented in user > code using subclasses in ES6. I'm particularly interested in the "lock > down in place" mechanism because it *cannot* be implemented in user code. > > And yes, i

Re: *.empty Idea

delete/etc it is still possible to mutate the map using > `Map.set.call(m, 'a', 'b');`. And there is no way for use code to get at > the [[MapData]] slot to protect it. > --scott > > > On Thu, Apr 30, 2015 at 2:42 PM, C. Scott Ananian > wrote: > >&g

Re: *.empty Idea

It doesn't matter. Others will do the same thing in ES6 and then break under your proposal in ES7. On Thu, Apr 30, 2015 at 11:42 AM, C. Scott Ananian wrote: > On Thu, Apr 30, 2015 at 2:22 PM, Mark S. Miller > wrote: > >> It would also not be compatible with ES6 code. SES

Re: *.empty Idea

. On Thu, Apr 30, 2015 at 11:18 AM, Mark S. Miller wrote: > Hi Scott, this would only be confusing. Object.tamperProof is built on and > implies Object.freeze. It is like Object.freeze except that it replaces > (some :( ) data properties with accessors in order to work around the &

Re: *.empty Idea

ave now. > --scott > > > On Thu, Apr 30, 2015 at 1:17 PM, Mark S. Miller > wrote: > >> This must *not* be hung off of Object.freeze. Object.freeze is about >> tamper proofing an object's API, not about making its internal state >> immutable. I regret the term &

Re: *.empty Idea

t are distinct from API tamper proofing but that do not extend to considering the mutability of the contents of the collections. I welcome proposals that would make sense for JavaScript. On Thu, Apr 30, 2015 at 9:52 AM, C. Scott Ananian wrote: > On Mon, Feb 23, 2015 at 3:31 PM, Mark S. Miller

Re: Subclassing ES6 objects with ES5 syntax.

On Wed, Apr 29, 2015 at 2:36 PM, C. Scott Ananian wrote: [...] > Mark, after you've slept on this and assuming you haven't changed your > mind, would you be willing to be the TC39 champion? I'm not a participant > in that process. > Yes. -- Cheers, --MarkM

Re: Subclassing ES6 objects with ES5 syntax.

On Wed, Apr 29, 2015 at 12:40 PM, C. Scott Ananian wrote: > On Wed, Apr 29, 2015 at 3:32 PM, Allen Wirfs-Brock > wrote: > >> On Apr 29, 2015, at 12:24 PM, C. Scott Ananian wrote: >> >> On Wed, Apr 29, 2015 at 3:09 PM, Allen Wirfs-Brock > > wrote: >> >>> class DefensivePromise extends Promise {

Re: Subclassing ES6 objects with ES5 syntax.

On Wed, Apr 29, 2015 at 11:12 AM, C. Scott Ananian wrote: > On Wed, Apr 29, 2015 at 2:07 PM, Mark S. Miller > wrote: > >> Hi Scott, I think your approach is on the right track. How about the >> following? >> >> Anyone see a way to attack it? >> &g

Re: Subclassing ES6 objects with ES5 syntax.

I do indeed need to expose DefensivePromise under the global name "Promise", replacing the builtin. Other than itself being frozen and making frozen promises, it should in all other ways conform exactly to the promise spec while still guaranteeing this invariant. > ``` > constructor(x) { >

Re: Subclassing ES6 objects with ES5 syntax.

Hi Scott, I think your approach is on the right track. How about the following? Anyone see a way to attack it? const goodPromises = new WeakSet(); class DefensivePromise { constructor(x) { super(x); if (new.target === DefensivePromise) { Object.freeze(this); goodPromises.a

Re: Subclassing ES6 objects with ES5 syntax.

On Wed, Apr 29, 2015 at 10:26 AM, C. Scott Ananian wrote: > On Wed, Apr 29, 2015 at 1:00 PM, Mark S. Miller > wrote: > >> The invariant I am interested in: >> >> In a realm where we (the trusted defender who runs first) make Promise >> defensive as follows >

Re: Subclassing ES6 objects with ES5 syntax.

I have not responded on list yet because I haven't yet been able to find the time to absorb this thread. But since Allen mentioned it, what I wrote was: The invariant I am interested in: In a realm where we (the trusted defender who runs first) make Promise defensive as follows * Freeze everyt

Re: Putting `global` reference in specs

in the long term, and not vice-versa > > Is this really that complicated to ship? > > On Fri, Apr 17, 2015 at 4:42 PM, Mark S. Miller > wrote: > >> >> >> On Fri, Apr 17, 2015 at 8:39 AM, Andrea Giammarchi < >> andrea.giammar...@gmail.com> wrote: >

Re: Putting `global` reference in specs

iscuss-boun...@mozilla.org] *On Behalf Of *Mark > Miller > *Sent:* April 17, 2015 11:53 AM > *To:* Glen Huang > *Cc:* Mark S. Miller; es-discuss@mozilla.org > *Subject:* Re: Putting `global` reference in specs > > > > This is one of several cases where, post ES6, we can pro

Re: Putting `global` reference in specs

ark Miller > Date: Friday, April 17, 2015 at 8:53 AM > To: Glen Huang > Cc: "Mark S. Miller" , "es-discuss@mozilla.org" < > es-discuss@mozilla.org> > Subject: Re: Putting `global` reference in specs > > This is one of several cases where, post ES6

Re: Putting `global` reference in specs

lts in Github for `typeof global` apparently got unnoticed ) > > On Fri, Apr 17, 2015 at 4:33 PM, Andrea Giammarchi < > andrea.giammar...@gmail.com> wrote: > >> it's a no-go under CSP so it's as bad as `Function('return this')()` >> >>

Re: Putting `global` reference in specs

On Fri, Apr 17, 2015 at 8:33 AM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > it's a no-go under CSP so it's as bad as `Function('return this')()` > Precisely. Which raises an interesting point. Does anyone know of a *precise* statement of the actual threat model that CSP's "no eval"

Re: Putting `global` reference in specs

I almost omitted it, but one should never need to encounter or think about sloppy code unless absolutely necessary. For my brain, adding the "use strict"; makes this snippet of code much simpler. On Fri, Apr 17, 2015 at 8:30 AM, Andreas Rossberg wrote: > On 17 April 2015 at

Re: Putting `global` reference in specs

(1,eval)('"use strict"; this') On Fri, Apr 17, 2015 at 8:23 AM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > there's actually no way, officially, to reference what ES2015 call *the > global object*, just pointless fragmentation between engines. > > > > On Fri, Apr 17, 2015 at 4:19 PM

<    1   2   3   4   5   6   7   8   9   10   >