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);
}
}
```
Currently because of an edge-case in Babel 6's class fields, every property
would need an initializer value, but that will be fixed in Babel 7. You can
see an example here:
https://babeljs.io/repl/#?babili=false&evaluate=true&lineWrap=false&presets=stage-2&targets=&browsers=&builtIns=false&debug=false&code_lz=EQVwzgpgBGAuBOBLAxrYBuAUJ5AbAhmGFAAoTxgD2AdlAN6ZRTX4C20AvFAMxZPI048EKkrwAFAEp6jJlADyAIwBWEVADoADvAgA3CNVgBRAB6wDYRIPGwAFojCT0UWQF9M7nINhRN5KrRc1BAA7qT-NFJYfhQ06vgA5pxQAEwA7OhAA&experimental=false&loose=false&spec=false&playground=false
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:
*
https://www.typescriptlang.org/play/index.html#src=%0D%0Aexport%20class%20Person%7B%0D%0A%20%20%20%20name%3B%0D%0A%7D%0D%0A%0D%0Aconst%20person%20%3D%20new%20Person()%3B%0D%0Aperson.age%20%3D%2027%3B
*
https://flow.org/try/#0PQKgBAAgZgNg9gdzCYAodBTAHgBzgJwBcwBjGAQwGdKwAFDfSuAOwG9UxOxnyBbDANyoAvuhItKxHAybMwAXm4Yk9RiwAUASiHS1zAHTkA5hgVgATAHYBQA
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 <naveen.c...@gmail.com>
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
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
