@strict class decorator

Tue Aug 8 13:40:52 UTC 2017

Name changes are fine but the type would remain the same, right?

On Tue, 8 Aug 2017 at 18:22 Sebastian Malton <sebastian at malton.name> wrote:

> That does sound very useful however it has to work (somehow) with NodeJS
> where the name of objects can change through requiring. Would the type be
> the original name or the name in the current file?
>
> *From:* naveen.chwl at gmail.com
> *Sent:* August 8, 2017 4:59 AM
> *To:* isiahmeadows at gmail.com; valentinium at gmail.com;
> es-discuss at mozilla.org
> *Subject:* Re: Re: @strict class decorator
>
> 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/4beb8565/attachment-0001.html>