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 domains. For example, I wouldn't have a library specific to "automotive vehicles" but something that would aid development across the board such as these I think could benefit. Hence why I think they are called "core-decorators"
On Tue, 8 Aug 2017 at 13:36 Isiah Meadows <[email protected]> wrote: > 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 <[email protected]> wrote: > >> 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. >> >> On Tue, 8 Aug 2017 at 11:16 Darien Valentine <[email protected]> >> wrote: >> >>> For a class which is not intended to be subclassable, this can be done >>> today >>> with `Object.preventExtensions()` or `Object.seal()`, depending on your >>> intent: >>> >>> class Foo { >>> constructor() { >>> this.bar = 1; >>> this.baz = 2; >>> >>> Object.preventExtensions(this); >>> } >>> } >>> >>> const foo = new Foo(); >>> >>> foo.bar = 3; // okay >>> foo.qux = 4; // throws in strict mode >>> >>> But this approach doesn’t work when subclassing is or may be in play. >>> It’s also not >>> directly possible with the decorator proposal as it stands today — but >>> there has >>> been discussion of it and it sounds like it’s something that’s on >>> people’s minds: >>> >>> [2017 July 27]( >>> http://tc39.github.io/tc39-notes/2017-07_jul-27.html#11ive-interaction-of-privacy-fields-and-decorators >>> ) >>> >>> > DE: Omitted features: instance finishers. Yehuda? >>> > >>> > YK: an instance finisher is a function that is executed at the end of >>> > instantiation of the class at any subclass level and passes at the >>> > instance. this is at the end of Reflect.construct. the use case is a >>> > decorator to confirm that all instances are frozen or sealed. Another: >>> > you want to register created instance into a map. The subclass provides >>> > the key, the superclass expresses that the instance should be >>> registered. >>> > >>> > DE: instance finishers change how instances are created. It's >>> > complicated and so wants to separate it out. >>> >>> ...looking forward to this, too. >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
