Re: Syntax Sugar for protected state

Does anyone help me with being TC39 champion for my personal protected state strawman? https://github.com/petamoriken/es-protected-state On 2016/01/20 1:43, 森建 wrote: > @Andrea Giammarchi > > Thank you for supporting my code, I got JavaScript knowledge a lot! > > @Subscribers > > If there is

Re: Assignments to SuperProperty are confusing and may be useless

Assignment to a super properly definitely has its uses, in the same way that calling a super method does, though definitely less common. Consider an example where a subclass wants to override a parent class's accessor property: ``` class Parent { get prop(){ return this._prop; } set

Assignments to SuperProperty are confusing and may be useless

Today I saw a V8 test case [1] which took me a long time to figure out why it runs like this: class Test { m() { super.length = 10;// `super.length' here has the same effect as `this.length' console.log(super.length);// but `super.length' here is

Re: Weak Reference proposal

On Fri, Feb 19, 2016 at 5:36 PM, John Lenz wrote: > The finalizer holdings, could itself could hold a reference to the > weakrefernce correct? > The holdings can certainly strongly point to the weakref itself, yes. There is no reason to think this is a mistake. By

Re: Weak Reference proposal

The finalizer holdings, could itself could hold a reference to the weakrefernce correct? On Fri, Feb 19, 2016 at 12:30 AM, Dean Tribble wrote: > Thanks for your comments. > > A practical answer to your question: If you drop references to a > subsystem that internally uses

Re: es7 proposal/polyfill?: base Map/WeakMap off Proxy + Weak References

On Fri, Feb 19, 2016 at 1:03 PM, Tab Atkins Jr. wrote: > On Fri, Feb 19, 2016 at 12:59 PM, Boris Zbarsky wrote: >> On 2/19/16 3:50 PM, Coroutines wrote: >>> Side discussion: Why does Javascript have this limitation? - what I >>> view as a limitation?

Re: es7 proposal/polyfill?: base Map/WeakMap off Proxy + Weak References

On Fri, Feb 19, 2016 at 12:59 PM, Boris Zbarsky wrote: > On 2/19/16 3:50 PM, Coroutines wrote: >> Side discussion: Why does Javascript have this limitation? - what I >> view as a limitation? You'd think this could be supported without >> breaking older JS.. > > I don't see how

Re: es7 proposal/polyfill?: base Map/WeakMap off Proxy + Weak References

On 2/19/16 3:50 PM, Coroutines wrote: Side discussion: Why does Javascript have this limitation? - what I view as a limitation? You'd think this could be supported without breaking older JS.. I don't see how it could. I'll bet $50 someone out there is using obj[location] for example.

Re: es7 proposal/polyfill?: base Map/WeakMap off Proxy + Weak References

On Fri, Feb 19, 2016 at 4:40 AM, Thomas Foster wrote: > Not sure where you got that idea, but aren't the objects just being converted > to string property names? Huh. I was so certain Node allowed that - I guess I just never made use of it. I knew that 'legally'

Re: Destructuring an object into a new object (like Underscore pick but ESier)

I like how your pick notation can combine easily with spread operators: let newObj = { ...obj.{foo, bar}, quux: 4} I think I actually prefer that to mine. Destructuring on the left side of a colon is sort of fighting against the spread operator, and might suggest a more natural syntax of { {*}:

Re: Destructuring an object into a new object (like Underscore pick but ESier)

Bob, the benefit of your proposed syntax would be that the object identifier comes first instead of last, so the reader can see the intent of the code sooner: ```js let newObj = {...obj.{foo, bar}, quux:4} ``` /#!/JoePea On Feb 19, 2016 9:55 AM, "Bob Myers" wrote: > Indeed, this

Re: Destructuring an object into a new object (like Underscore pick but ESier)

> > I can create a new object with ALL of these properties using a spread > operator: > let newObj = {...obj, quux: 4} > Let's not do this. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Destructuring an object into a new object (like Underscore pick but ESier)

Please see https://github.com/sebmarkbage/ecmascript-rest-spread On Fri, Feb 19, 2016 at 11:32 AM, Zacqary Adam Xeper < zacqary.xe...@datadoghq.com> wrote: > So let's say I have: > let obj = {foo: 1, bar: 2, baz: 3} > > And I want to initialize a new object that looks like: > {foo: obj.foo, bar:

Destructuring an object into a new object (like Underscore pick but ESier)

So let's say I have: let obj = {foo: 1, bar: 2, baz: 3} And I want to initialize a new object that looks like: {foo: obj.foo, bar: obj.bar, quux: 4} I can create a new object with ALL of these properties using a spread operator: let newObj = {...obj, quux: 4} But if I want to initialize a new

Re: es7 proposal/polyfill?: base Map/WeakMap off Proxy + Weak References

> Map's API could just go away and follow traditional Object assignment > and existence checks: > > map[key] = value; > > // wish JS had a null-coalescing `?` operator like Coffeescript.. > if (map[key] !== undefined || map[key] !== null) { ... } > > It's totally legal in non-Node JS to have

Re: Error stack strawman

On 19 February 2016 at 10:29, Andreas Rossberg wrote: > On 19 February 2016 at 06:29, John Lenz wrote: > >> However, at the CPU level, it seems like you would be better pushing an >> return address for a special function that indicated the start of a

Re: es7 proposal/polyfill?: base Map/WeakMap off Proxy + Weak References

On Fri, Feb 19, 2016 at 1:17 AM, Coroutines wrote: > Hi - I hope I am not suggesting something that has been said before ~ > > Having Proxy and eventual Weak References makes it possible to build > Map/WeakMap in plain JS - nothing in hidden, 'native code' (C++). > Not

Re: Error stack strawman

On 19 February 2016 at 06:29, John Lenz wrote: > However, at the CPU level, it seems like you would be better pushing an > return address for a special function that indicated the start of a > sequence of tail calls. That way you trade only some > complexity/performance

Re: Error stack strawman

On 19 February 2016 at 03:13, Gary Guo wrote: > Andreas wrote: > > This would be fairly difficult to support by implementations. In V8, for > example, we currently have no way of reconstructing that information, nor > would it be easy or cheap to add

es7 proposal/polyfill?: base Map/WeakMap off Proxy + Weak References

Hi - I hope I am not suggesting something that has been said before ~ Having Proxy and eventual Weak References makes it possible to build Map/WeakMap in plain JS - nothing in hidden, 'native code' (C++). I'd like to propose basing them off of these when Weak References are a 'thing'. Map's API

Re: Weak Reference proposal

Thanks for your comments. A practical answer to your question: If you drop references to a subsystem that internally uses weak references, the "finalization" it would engage is just death throes. For example, if you drop an Xml parser, then there's no reason to muck out it's internal cache since