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 n
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 prop
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
`Test.prototype.__proto__.leng
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 contrast, though we cannot pre
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 weak references, the "
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? You'd think this could be supported without
>
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 it could. I'll bet
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.
-Bori
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' Map was the only place you cou
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 { {*}: o
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 is the exact ob
>
> 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
Indeed, this is the exact objective of the pick notation which I proposed
about six months ago, and have now greatly refined and also implemented a
proof-of-concept.
In the previous incarnation, I called this a "pick operator" and
represented it with `#`, but now I treat it as an extension of dot
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 ob
> 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 Ob
Oh and note that if the current version of the proposal (459f825) were
implemented, it would not be usable for jsdom. This is because of the
authority constraints. jsdom supports being run within a different
browser (e.g. so that you can parse html within a Worker, which does
not provide access to
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
>> sequence of tail calls. That way you trad
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 quite. This is why ephemer
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 for tail calls (an inspec
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 that. A frame is created by the callee,
> but
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
23 matches
Mail list logo
