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 <[email protected]> wrote: > 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
