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?

Sent: August 8, 2017 4:59 AM
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 <> 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 <> 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 <> 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 <> 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 <> 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 <> 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 <> 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() { = 1;
        this.baz = 2;


    const foo = new Foo(); = 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:

> 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 mailing list
es-discuss mailing list

Reply via email to