Activity

1. Mohamed Hegazy (mhegazy)

   closed this as completedon Nov 17, 2017
2. Mohamed Hegazy (mhegazy)

   added

   Design NotesNotes from our design meetingsNotes from our design meetings

   on Nov 17, 2017
3. DanielRosenwasser commented on Nov 17, 2017

   

   Daniel Rosenwasser (DanielRosenwasser)

   on Nov 17, 2017

   Last edited by DanielRosenwasser

   Member

   More actions

   My notes:

   ---

   Strict Property Initialization Checks in Classes

   • Does adding | undefined to a declaration, do we still do initialization checking within the constructor?
     • No, it's in the domain, allowed not to initialize it.
     • What about with generics that have undefined as a constraint?
       • No, only signals it could be instantiated with undefined
   • What about @decorated property declarations?
     • People can always opt out of this.
     • Code in the RWC doesn't break because they don't opt into strict.
   • Does it make sense to have a modifier for this?
     • ! after the property name.
     • lateinit? Some sort of modifier to assure the compiler it doesn't need to write any checks.
     • Should we error on initialized declarations like a!: number = 10?
       • Probably should let linters take over this.
     • Make it !, it reflects expression level non-null assertion logic.
       • Allow it on locals.
       • But don't allow it on const.
       • Also, probably error when we give an initializer (nix that last point about linters taking this on)
       • But allow it on readonly.
   • What about local methods that can be called from the constructor that might observe uninitialized values.
     • Only so far we can go.
4. tinganho commented on Nov 19, 2017

   

   Tingan Ho (tinganho)

   on Nov 19, 2017

   Contributor

   More actions

   you can bang these properties

   This sounds funny.

   Nearly all of our classes are handled by some sort of IoC container.

   Sometimes(99% in my case) classes, are just definitions and construction is "inversioned". The IoC container takes care of construction of the class. I don't want the compiler to complain in these type of classes. And providing a flag to opt-out or banging all the properties doesn't sound optimal either.

   One suggestion, I can think of, at least for the decorator use case, is to have a modifier on the "definition" class decorator.

   In the below example you can see a constructtarget modifier:

   export function Entity(definitions?: EntityDefinitions) {
       return constructtarget function(target: any) {
           //...
       };
   }

   And applying it on entity definitions will not cause any errors:

   @Entity()
   class User {
       @Column()
       name: string; // no error
       @Column()
       age: number; // no error
   }

   Example from TypeOrm https://github.com/typeorm/typeorm.

   👍React with 👍1Reacted by Herrington Darkholme
5. DanielRosenwasser commented on Nov 19, 2017

   

   Daniel Rosenwasser (DanielRosenwasser)

   on Nov 19, 2017

   Member

   More actions

   We discussed decorators that can declare how they modify the target, so it's an option, but others in the meeting felt like doing so shouldn't be a blocker for the flag as it exists today.
6. mihailik commented on Nov 22, 2017

   

   mihailik

   on Nov 22, 2017

   Contributor

   More actions

   Should this flag hold off from graduating to --strict set?

   If it needs to be disabled for a all/large subset of angular code out there, perception of TS as a stable platform might be affected.
7. mhegazy commented on Nov 22, 2017

   

   Mohamed Hegazy (mhegazy)

   on Nov 22, 2017

   ContributorAuthor

   More actions

   Should this flag hold off from graduating to --strict set?

   we have the infrastructure in place to opt-out of specific --strict flags as needed. --strict --strictPropertyInitialization false. --strict by definition means you are accepting breaking changes between releases. if this is not your intention, then do not use --strict and instead spell out the flags you are interested in, e.g. --noImplictAny --strictNullchecks

   👍React with 👍1Reacted by mihailik
8. mihailik commented on Nov 22, 2017

   

   mihailik

   on Nov 22, 2017

   Contributor

   More actions

   Hope you're right — regardless of technical reasoning you still want gain > pain to proceed
9. tinganho commented on Nov 22, 2017

   

   Tingan Ho (tinganho)

   on Nov 22, 2017

   Contributor

   More actions

   I think many people would rather bang all properties than setting the flag, to just keep the default "strict" mode. But I hope the TS team can hold this off a bit, certainly a contentious topic. As of right now, it feels like a choice between pest and colera.
10. microsoft

    locked and limited conversation to collaborators on Jun 14, 2018