SUGGESTIONS: getters/setters in interface

[dungdm93]

In TypeScript, we define abstract property in interface like:

interface I {
    prop: string; // abstract property = getter + setter
}

But there are no way to define only setter.
And currently we can use readonly property to defne abstract getter like:

interface IReadonly {
   readonly foo: string; // abstract getter, not un-reassignable property as expect
}

Even that, I realize that readonly have many drawbacks as:

1. ambiguous meaning

   When using readonly keyword, most people expect an un-reassignable property (as they are in class). However, in interface it declare an abstract getter.
   In bellow example, some guys implement readonly property as computed property.

   class CComputed implements IReadonly {
       private first: string;
       private second: string;
   
       get foo(): string {   // It that bad?
           return `${this.first} ${this.second}`;
       }
   }

2. missing implement

   Because interface make no distinction between regular properties and accessor properties. So compiler can't detect errors if child classes don't implement correctly.

   // no foo's getter, but no compile error at all.
   class CReadonly implements IReadonly {
       third: string;
       set foo(value: string) {
           this.third = value;
       }
   }

   Suggestion

I'd like to suggest that abstract getter/setter (accessors) is allowed in interface.

• Setter

interface ISetter {
    set bar(value: string);
}

//===== Some implementation examples =====
// OK
class CSetter1 implements ISetter { // OK
    public bar: string = "Batman";
}

// OK
class CSetter2 implements ISetter {
    private secret: string = "Superman";
    set foo(value: string) {
        this.secret = value;
    }
}

// Compile error: Implement setter 'bar' is missing.
class CSetter3 implements ISetter {
    public readonly bar: string = "Iron Man";
}

// Compile error: Implement setter 'bar' is missing.
class CSetter4 implements ISetter {
    get bar(): string {
        return "Captain America";
    }
}

let iSetter: ISetter = { bar: "Thor" }; // OK

• Getter

interface IGetter {
    get foo(): string;
}

//===== Some implementation examples =====
// OK
class CGetter1 implements IGetter {
    public foo: string = "Batman";
}

// Compile error: Implement getter 'foo' is missing.
class CGetter2 implements IGetter {
    private secret: string = "Superman";
    set foo(value: string) { // Error
        this.secret = value;
    }
}

// OK
class CGetter3 implements IGetter {
    get foo(): string {
        return "Captain America";
    }
}

// OK
class CGetter4 implements IGetter {
    public readonly foo: string = "Iron Man";
}

let iGetter: IGetter = { foo: "Thor" }; // OK

[RyanCavanaugh]

What's the difference between this and readonly name: string supposed to be?

[HerringtonDarkholme]

There is runtime difference. getter has get function in descriptors, but readonly does not necessarily have.
But this is runtime difference, so adding this to type system is contrary to TypeScript's design, isn't it?

[dungdm93]

@RyanCavanaugh readonly indicate un-reassignable property.
While getter can be used as computed property. For examble:

class Person {
    public firstName: string;
    public lastName: string;

    constructor(firstName: string, lastName: string) {
        this.firstName = firstName;
        this.lastName = lastName;
    }

    public get fullName() {
        return `${this.firstName} ${this.lastName}`;
    }
}

let p: Person = new Person("Bruce", "Wayne");
alert(p.fullName);   // Bruce Wayne

p.firstName = "Clark";
p.lastName = "Kent";
alert(p.fullName);   // Clark Kent

[kitsonk]

@dungdm93 but that makes no difference from an interface perspective. p.fullName is of a type string and cannot be assigned a value. What difference would it make from an interface perspective?

[dungdm93]

@kitsonk OK. maybe my example make confused.
So about if I wan to declare setter only Interface?

[kitsonk]

Then it is a dupe of #11596 or #10196 or #3757 or many other ones.

[dungdm93]

Using readonly in interface make people so confused.
From my aspect, allow getter/setter declared in interface make more sense.
Reference

[kitsonk]

Why is it confusing?

The interface describes the types of an interface, not the implementation, the the ability to assign values. You are suggesting that the interface should concern itself with implementation details? That is unsound.

For example, from an interface perspective what is the difference between a getter only property that returns a string and a non-writable property that has a value of string? Why would the interface be concerned about that distinction?

[dungdm93]

I'm not mean the interface should care about implementation details itself.

readonly in class and interface have difference meaning. In the class, it define an un-reassignable property. However, in the interface, it declare a abstract getter. So that is why it make many people confusing at the first time.

So my suggestion is allow abstract getter act the same as readonly work in interface. You can consider it as more sensible alternative syntax. Furthermore, there are no writeonly keyword to declare abstract setter, but using this syntax you can.

[kitsonk]

In regards to writeonly Mohammed expressed that it is so obscure that the feeling is that it isn't worth the overhead in modelling it in the type system. (see: #11596) But if you feel there is real world value in such a use case, then I would add your arguments to that issue.

Again, as far as read only, what is the difference between:

interface Foo {
    readonly foo: string;
}

class FooA implements Foo {
    readonly foo: string;
    constructor() {
        Object.defineProperty(this, 'foo', {
            value: 'bar',
            writable: false,
            enumerable: true,
            configurable: true
        });
    }
}

class FooB implements Foo {
    get foo(): string {
        return 'bar';
    }
}

Answer is nothing. There is more than one way of implementing a read only property in JavaScript, therefore the interface shouldn't be concerned about implementation.

[RyanCavanaugh]

Just to say this explicitly, because there seems to be some confusion: readonly is not const!. It has never meant const and it would be straight-out wrong to conflate the two. A custom Stack implementation, for example, would have a readonly length property, but it wouldn't be const (unless you wanted the stack to always be empty)

[dungdm93]

@RyanCavanaugh So sad. I totally known the difference between readonly and const.
Forget readonly, it's NOT my main focus. I just wanna interface support a feature of class:

abstract class Abstract {
    abstract set foo(value: string);
    abstract get bar(): string;
}

class Concrete implements Abstract { // Make class be interface => It's work
    private f: string;
    private b: string;

    set foo(value: string) {
        this.f = value;
    }

    get bar(): string {
        return this.b;
    }
}

Why we can't declare like:

interface Abstract {
    set foo(value: string);
    get bar(): string;
}

[mhegazy]

An interface represents a contract, a shape, not how it is implemented.

In JS there are two ways to implement properties, either as property declarations, or as accessors. From the user of the object perspective it does not matter.

Consider this:

var i1 = {
    p: 1
};

var i2 = {
    get p() { return 1; }
    set p(v) { }
};

From the user perspective, both i1 and i2 have the same shape. they have a property called p on them that is a number, and you can both read it and write it. how they are implemented is not martial for the user.

Thus the type is:

interface I {
    p: number;
}

hope this makes it clear.