Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

immutable types #11535

Closed
zpdDG4gta8XKpMCd opened this issue Oct 11, 2016 · 9 comments
Closed

immutable types #11535

zpdDG4gta8XKpMCd opened this issue Oct 11, 2016 · 9 comments
Labels
Duplicate An existing issue was already created

Comments

@zpdDG4gta8XKpMCd
Copy link

zpdDG4gta8XKpMCd commented Oct 11, 2016

situation:

  • i need an interface 100% similar to a given one but with all properties readonly:

    interface MyConfig {
       name: string;
       settings: MySettings
    }
    interface MySettins {
      values: string[];
    }

problem:

  • in order to get MyConfig immutable i have to effectively re-declare it with all properties which is a lot of work and maintenance:

    interface MyConfigReadOnly {
       readonly name: string;
       readonly settings: MySettingsReadOnly;
    }
    interface MySettingsReadOnly {
      readonly values: ReadOnlyArray<string>;
    }

solution:

  • allow special declaration that produces a readonly version of an interface based on the original one :

    interface MyConfigReadOnly readonly MyConfig {
        // <-- notice here how we saved some work redeclaring the name property!
        settings: MySettingsReadOnly;
    }
    interface MySettingsReadOnly readonly MySettings {
        values: ReadOnlyArray<string>;
    }
@sandersn
Copy link
Member

Note that a proposal and implementation would be nearly identical to subset types at #11233, just with a different operator.

@sandersn
Copy link
Member

@andy-ms points out that if we implement this as a type operator, the syntax should probably be const T

@ahejlsberg
Copy link
Member

@sandersn Actually, there would be a significant difference from subset types in that readonly (or const) would be a deep operation, whereas subset is shallow.

@zpdDG4gta8XKpMCd
Copy link
Author

proposed solution is suitable for both deep and shallow

@zpdDG4gta8XKpMCd
Copy link
Author

zpdDG4gta8XKpMCd commented Oct 11, 2016

alternatively it would be great to get #11536 #4892 (comment) and generate DIY'ed readonly interfaces

@NoHomey
Copy link

NoHomey commented Oct 11, 2016

In addition I would like to purpose a readonly interface: a interface where all members are implicitly marked as readonly:

situation:

  • I need an interface with all members beeing readonly:
interface RegularInterface {
    regularMember: string;
}

interface AllReadOnlyInterface {
    readonly memberA: number;
    readonly memberB: number;
    readonly regular: ReagularInterface;
}

problem:

  • All member must be explicitly marked as readonly.

solution:

  • Add a interface specifer readonly like enum has const enum (const enum has different meaning to the compiler but it just as example of the purposal)
interface RegularInterface {
    regularMember: string;
}

readonly interface AllReadOnlyInterface {
    memberA: number; // memberA is readonly
    memberB: number; // memberB is readonly
    regular: ReagularInterface; // regular is readonly
}

@aluanhaddad
Copy link
Contributor

aluanhaddad commented Oct 12, 2016

@Aleksey-Bykov I really want to see this in the language. It helps to solve a myriad of recent issues and allows for some very flexible programming models. It has lots of practical applications. For example wanting to retrieve and expose immutable data from an Http client but allowing a mutable POST object to be built up using a mutable (the default) version of the same type.

It also fills a nice conceptual space in the language and helps to build idiomatic, JavaScript-embracing correspondence between compile time and runtime strictness.

We could finally get fairly accurate, highly useful type definitions for functions such as deep-freeze-strict. This would be a big win.

@NoHomey
I believe this proposal already covers that and more.

@kitsonk
Copy link
Contributor

kitsonk commented Oct 12, 2016

This is a dupe of #10725 (search is our friend).

Also, this (the shallow version) would model Object.frozen() as well.

It relates to detecting frozen objects in CFA (see: #11481 and #11180).

@mattmccutchen
Copy link
Contributor

In case anyone finds this issue in a search, it's about read-only interfaces, not immutable ones, despite the title. The correct issue for immutable interfaces is #14909.

@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

8 participants