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
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
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
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
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
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?
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
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.
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'
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 { {*}:
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
>
> 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
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:
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
> 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
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
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
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
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
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
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
21 matches
Mail list logo