@strict class decorator

[Naveen Chawla]

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 <isiahmeadows at gmail.com> 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 <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/ba8a3d8d/attachment-0001.html>