@strict class decorator

[Naveen Chawla]

Sorry my writing style was bad. I meant if or when there is an introduction
of types in parameters (like in ActionScript, TypeScript etc.) e,g,
`sayHelloToPerson(person : Person);` which I said I'd like

On Tue, 8 Aug 2017 at 14:02 Isiah Meadows <isiahmeadows at gmail.com> wrote:

> 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/6be32303/attachment.html>