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

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

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

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 >

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

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

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

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

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

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

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

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

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

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!) > >

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

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

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

Re: Re: @strict class decorator

Ah great! So then how about having a `@seal` and/or `@preventExtensions` decorator as a shorthand? I accept that IDEs can only do so much in checking your code, and beyond that, you're on your own... Secretly I want Javascript to become like TypeScript... all optional, backwards compatible, etc.

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

On Tue, Aug 8, 2017 at 7:18 AM, Naveen Chawla wrote: > It'd be great to know if anyone from TC39 is going to propose these > ideas (could I submit a README.md in order to help? If so where?) Proposals come from the community (of which TC39 members are a part). What you've

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

Another benefit of iterable toObjectByProperty(element=>element.id) is that it can be placed at the end of a transformation chain of `map` `sort` `filter` `concat` etc.: ``` const cache = sourceIterable .filter(item=>item.isValid)

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

> I haven't seen any suggestions for anything different than those three patterns; am I missing something? The draft I assembled does follow that pattern, but there was [another approach suggested](https://esdiscuss.org/topic/array-prototype- toobjectbyproperty-element-element-property#content-2)