Are there some good approach to remove 'readonly' restriction templorary from fields?

[tetsuharuohzeki]

environment

• [email protected]

description

relate? : #6532

In some case (e.g. to development framework), I'd like to do a destruct operation for the members which is restricted as readonly to release a some large object explicitly. But it would be the compile error if I assign a value to the restricted member in a non-constructor() method.

class A {
  readonly a: SomeLargeObject;
  constructor(a: SomeLargeObject) {
    this.a = a;
  }

  // explicit destructor
  destroy(): void {
    // release this some large object explicitly
    this.a = null; // <-- compile error
    (<any>this).a = null; // <-- no problem
    (<MutableA>this).a = null // <--- no problem
  }
}

interface MutableA {
  a: SomeLargeObject;
}

I know we can avoid this error if casting this to any type, but it would not be a type safe. In other approach, we can also do it if we define a "mutable" interface and cast to it, but it would be wordy....

Are there some good approach to remove 'readonly' restriction templorary?

[ahejlsberg]

I'd propose using a public get accessor with a private backing field. There's no way to temporarily remove readonly as that would sort of defeat the purpose of the feature.

[tetsuharuohzeki]

I'd propose using a public get accessor with a private backing field.

I also thought the following usecase, so its escape hatch is like a C++'s const_cast<T>()
The public get accessor is defensive from external operation, but it cannot guard from internal operation.

class B {
   // I'd not like to modify this field only in a constructor/destructor
   private b: SomeLargeObject;

   constructor(b: SomeLargeObject) {
      this.b = SomeLargeObject;
   }

   bar(): void {
     var blahblah = createSomeLargeObject();
     this.b = blahblah; // I'd like to ban this operation.
   } 

   destroy(): void {
      this.b = null; // I'd like to allow this.
   }
}

[pablobirukov]

@saneyuki This is allowed in 2.0.3

public destroy() {
    delete this.scheduler; 
    delete this.stream;
    ...
}

[mhegazy]

@R00GER ideally this should be reported as an error. deleting should follow the same rules as writing. #11480 tracks making this an error.