Alwin Garside

This is one of my favorite TypeScript features. But what has me even more excited is the ability to add properties to interfaces.

Soon we'll be able to fully describe simple structures in interfaces. Anyone who has ever done serious TypeScript coding in CDK knows how powerful this is.

It certainly is a fancy feature, but it takes too much a toll on the cognitive load.

Right now visibility is straight-forward. In a glance I can map in my head the possible operations on a property when I see its visibility. Adding this to the language will mean there will be moments that I'll have to stop and work out exactly what it means I can do with a property.

Also, property hooks already solve these use cases: defining a virtual property hook with only a getter will prevent you from setting the property, and vice versa.

I always thought it was weird that the new <class> operator apparently had a lower precedence than a method call.

To me parenthesis always just means "we need group this set of operations to ensure they're interpreted in the correct order". Given that all else being equal, precedence goes from left to right, the class constructor requiring its precedence to be overridden implies it is a lower precedence.

This RFC fixes that; it gives the constructor equal precedence to other method calls and if you simply read from left to right, it makes sense the new <class> will be executed first, and then the method call.

Anyone arguing that the old syntax is more readable is insane. Who in their right mind would willfully prefer adding more repeated closing parentheses?

$foo = (new MyClass(new OtherClass('foo')))->doSomething();

vs

$foo = new MyClass(new OtherClass('foo'))->doSomething();

It may seem the old syntax is more readable, because you're used to it. However, all things being equal, without any bias, adding more parenthesis will objectively increase cognitive load.

At any rate, if you prefer more parentheses, this feature won't stop you from adding as much parentheses as you like.

C#-inspired properties, yes please!

This is good to have.

Properties are useful for exchanging (reading and writing) single values. Properties are good for data binding, etc.

With this RFC we can implement:

• Validation
• Trigger events
• Call methods if there is more to do

Update: About the $field I am not sure. Having a separate backing field can have some advantages.