@strict class decorator

[Naveen Chawla]

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 <isiahmeadows at gmail.com> 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 <naveen.chwl at gmail.com> 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 <valentinium at gmail.com>
>> 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
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170808/398be2e7/attachment.html>