@strict class decorator

[Isiah Meadows]

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