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 Isiah Meadows <[email protected]> wrote: > 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 line extra in the > constructor. > > On Tue, Aug 8, 2017, 04:18 Naveen Chawla <[email protected]> wrote: > >> 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
