Re: @strict class decorator

Subclassing can work too. ```js class A { constructor() { this.bar = 1; this.baz = 2; if (new.target === A) Object.preventExtensions(this); } } class B extends A { constructor() { super(); this.bat = 3; if (new.target === B) Object.preventExtensions(this); } } ``` No decorator needed to

Re: Proxy performance: JIT-compilation?

> On Aug 8, 2017, at 5:03 PM, Mark Miller wrote: > > So from y'all's various implementation perspectives, how does > https://github.com/tvcutsem/es-lab/issues/21 > look? Do you think it would > make it easier to achieve much higher performance pr

Re: Proxy performance: JIT-compilation?

So from y'all's various implementation perspectives, how does https://github.com/tvcutsem/es-lab/issues/21 look? Do you think it would make it easier to achieve much higher performance proxies than we could without these subtle semantic changes? Or do you think we can as easily achieve these perfor

Re: Proxy performance: JIT-compilation?

Yes, it's possible to optimize them using specialized ICs on the proxy handler itself, but it would be *far* easier to optimize it if the ICs weren't necessary in the first place, since you can just build it into the proxy's type, almost like a lazily-generated vtable. It's just far less work than

Re: Proxy performance: JIT-compilation?

On Fri, Aug 4, 2017 at 4:52 PM, Allen Wirfs-Brock wrote: > > On Aug 4, 2017, at 2:22 PM, Mark S. Miller wrote: > > At https://github.com/tvcutsem/es-lab/issues/21 Tom and I have an idea (that > we should turn into a proposal) for a subtle change to proxy semantics that > * should break essent

Re: @strict class decorator

Name changes are fine but the type would remain the same, right? On Tue, 8 Aug 2017 at 18:22 Sebastian Malton wrote: > That does sound very useful however it has to work (somehow) with NodeJS > where the name of objects can change through requiring. Would the type be > the original name or the n

Re: @strict class decorator

That does sound very useful however it has to work (somehow) with NodeJS where the name of objects can change through requiring. Would the type be the original name or the name in the current file?

Re: Re: Array.prototype.toObjectByProperty( element=>element.property )

OK thanks for the link - can you explain where the complexity is in my proposal? On Tue, 8 Aug 2017 at 16:14 T.J. Crowder wrote: > On Tue, Aug 8, 2017 at 11:39 AM, Naveen Chawla > wrote: > > Furthermore, if you use entries, this allows `[key, value]` entries > > with object keys to be transform

Re: Re: Array.prototype.toObjectByProperty( element=>element.property )

On Tue, Aug 8, 2017 at 11:39 AM, Naveen Chawla wrote: > Furthermore, if you use entries, this allows `[key, value]` entries > with object keys to be transformed into objects (which is not > allowed by `Object.fromEntries`): With respect, please do have a *thorough* read of my first reply in this

Re: Re: Array.prototype.toObjectByProperty( element=>element.property )

Furthermore, if you use entries, this allows `[key, value]` entries with object keys to be transformed into objects (which is not allowed by `Object.fromEntries`): ``` const cache = entries.toObject(entry=>entry[0].type, entry=>entry[1]); ``` On Tue, 8 Aug 2017 at 15:52 Naveen Chawla wrote: > P

Re: Re: Array.prototype.toObjectByProperty( element=>element.property )

Philosophically I agree completely with this principle. This does not have a bunch of options: ``` iterable.toObject(keyFromElement[, valueFromElement]) ``` What I proposed has only 1 variant: the fact that `valueFromElement` has a default if you don't provide it. Objects as they are are simple

Re: Re: Array.prototype.toObjectByProperty( element=>element.property )

On Tue, Aug 8, 2017 at 10:01 AM, Naveen Chawla wrote: > > Yeah except in what I'm saying it's optional My point is you'd use the right tool for the job at hand, rather than having a single tool with a bunch of options making it complex to explain, use, and optimize. If you review my earlier sugge

Re: Re: Array.prototype.toObjectByProperty( element=>element.property )

Yeah except in what I'm saying it's optional On Tue, 8 Aug 2017 at 14:16 T.J. Crowder wrote: > On Tue, Aug 8, 2017 at 9:39 AM, Naveen Chawla > wrote: > > I'd like to propose an enhancement to my proposal: > > ... > > It offers the same functionality, but in addition a second > > optional parame

Re: Re: @strict class decorator

Sorry my writing style was bad. I meant if or when there is an introduction of types in parameters (like in ActionScript, TypeScript etc.) e,g, `sayHelloToPerson(person : Person);` which I said I'd like On Tue, 8 Aug 2017 at 14:02 Isiah Meadows wrote: > Yeah, I would've checked had I been on a c

Re: Re: Array.prototype.toObjectByProperty( element=>element.property )

On Tue, Aug 8, 2017 at 9:39 AM, Naveen Chawla wrote: > I'd like to propose an enhancement to my proposal: > ... > It offers the same functionality, but in addition a second > optional parameter for the "value" in case you want something > other than the array element as the value. By default, if t

Re: Re: Array.prototype.toObjectByProperty( element=>element.property )

I'd like to propose an enhancement to my proposal: ``` const cache = iterable.toObject(item=>item.key, item=>item); //2nd param is optional, default shown ``` It offers the same functionality, but in addition a second optional parameter for the "value" in case you want something other than the ar

Re: Re: @strict class decorator

Yeah, I would've checked had I been on a computer, not a phone... ;-) Out of curiosity, though, what do you mean by if/when types? I don't recall hearing about it. On Tue, Aug 8, 2017, 04:30 Naveen Chawla wrote: > Nope not there (according to a Co+F keyboard search!) > > Use case is any time so

Re: Re: @strict class decorator

Nope not there (according to a Co+F keyboard search!) Use case is any time someone wants basic strict typing during development, but I agree it's not quite as compelling as if/when types in params (e.g. : Person) are introduced in Javascript (which I'd like honestly) On Tue, 8 Aug 2017 at 13:52 I

Re: Re: @strict class decorator

I think it might be just `@sealed` (`preventExtensions` not available), but I'm just going off the top of my head. I'd probably recommend it there rather than in the spec. I personally see minimal value in it being in the spec proper, because the use case is hardly there, and it's pretty much one

Re: Re: @strict class decorator

Hi! I don't see them. Which ones in `core-decorators` are they? Apart from removing a dependency that could be very commonly used, you would be right although I see that as a very compelling case in of itself. I see standard library as a good place for widely useful tasks that span all industry do

Re: Re: @strict class decorator

IIRC, the module `core-decorators` (a module of utility decorators) have both of those. That seems ideal, since it's not something that would massively benefit from being within the standard library itself. On Tue, Aug 8, 2017, 02:32 Naveen Chawla wrote: > Ah great! So then how about having a `@