@strict class decorator

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

@strict class decorator

Naveen Chawla
So here it is, the holy grail of allowing classes to have fixed definitions...

OK what do I mean?

suppose

```
@strict
export class Person{
    name;
}
```
 
is followed by

```
const person = new Person();
person.age = 27;
```

I would like to see the IDE flag it as " "age" is not a property in strict class "Person" "

This reminds the developer to then add age as a property, thereby ensuring every instance of the class always has full autocomplete, quick property renaming etc. across the project, for all properties added to it. For large projects with multiple developers this can also have the benefit of ensuring that all properties added to each instance are necessarily documented in one place, instead of checking whether someone has dynamically added a property somewhere.

I would expect this example to throw a runtime exception like @readonly does. I don't think that's a problem because I think the IDE would inform much sooner. But I'm open to the idea of the runtime allowing it, since the real benefit for me is during development. Maybe instead a `@strictDev` decorator for that behavior, not sure.

Support?

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: @strict class decorator

Logan Smyth
Not necessarily 100% what you're going for, but you can get an error for this behavior if you use `Object.preventExtensions()` on the class, e.g.

```
class Person {
  name;
  constructor() {
    Object.preventExtensions(this); 
  }
}
```


As for the IDE errors, it doesn't seem like `@strict` would be enough, because there are plenty of dynamic ways that you could pass class constructors or instance objects around that would cause an IDE to lose track of what objects to look at. This is the type of problem that Flowtype and Typescript already aim to solve, since the type annotations and inference allow them to track what types go where. They also already provide nice IDE errors for just this situation:


Given the limitations of type inference without an explicit typechecker, it doesn't seem like an annotation like `@strict` could be powerful enough to be useful for an IDE usecase. And for the non-IDE usecase, `Object.preventExtensions` seems to do what you want already.

On Mon, Aug 7, 2017 at 10:14 PM, Naveen Chawla <[hidden email]> wrote:
So here it is, the holy grail of allowing classes to have fixed definitions...

OK what do I mean?

suppose

```
@strict
export class Person{
    name;
}
```
 
is followed by

```
const person = new Person();
person.age = 27;
```

I would like to see the IDE flag it as " "age" is not a property in strict class "Person" "

This reminds the developer to then add age as a property, thereby ensuring every instance of the class always has full autocomplete, quick property renaming etc. across the project, for all properties added to it. For large projects with multiple developers this can also have the benefit of ensuring that all properties added to each instance are necessarily documented in one place, instead of checking whether someone has dynamically added a property somewhere.

I would expect this example to throw a runtime exception like @readonly does. I don't think that's a problem because I think the IDE would inform much sooner. But I'm open to the idea of the runtime allowing it, since the real benefit for me is during development. Maybe instead a `@strictDev` decorator for that behavior, not sure.

Support?

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: @strict class decorator

Darien Valentine
In reply to this post by Naveen Chawla
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:


> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: @strict class decorator

Naveen Chawla
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 <[hidden email]> 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:


> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: @strict class decorator

Isiah Meadows-2

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 <[hidden email]> 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 <[hidden email]> 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:


> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: @strict class decorator

Naveen Chawla
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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:


> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: @strict class decorator

Isiah Meadows-2

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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:


> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: @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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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:


> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: @strict class decorator

Isiah Meadows-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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:


> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: @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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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:


> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: @strict class decorator

Sebastian Malton
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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:


> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: @strict class decorator

Naveen Chawla
In reply to this post by Naveen Chawla
Name changes are fine but the type would remain the same, right?

On Tue, 8 Aug 2017 at 18:22 Sebastian Malton <[hidden email]> 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?

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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:


> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: @strict class decorator

Michael Theriot
Subclassing can work too.

```js
class A {
  constructor() {
this.bar = 1;
this.baz = 2;
if (new.target === A) Object.preventExtensions(this);
  }
}

class B extends A {
  constructor() {
super();
this.bat = 3;
if (new.target === B) Object.preventExtensions(this);
  }
}
```

No decorator needed to do this today.

I am not keeping up with decorators but @sealed implies to me that the class cannot be subclassed? At least that's what it means in C# and would confuse me if it simply meant Object.seal(this)...

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss