@strict class decorator

[Isiah Meadows]

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 <naveen.chwl at gmail.com> 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 <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/7262cfad/attachment.html>