fosstodon.org is one of the many independent Mastodon servers you can use to participate in the fediverse.
Fosstodon is an invite only Mastodon instance that is open to those who are interested in technology; particularly free & open source software. If you wish to join, contact us for an invite.

Administered by:

Server stats:

10K
active users

– surprisingly tricky to fix:

type Incrementor = {
inc(): void,
};
function createIncrementor(start = 0): Incrementor {
return {
counter: start, // error
inc() {
this.counter++; // error
},
};
}

Best solution (AFAICT): Assign object to variable, return variable (then excess properties are allowed).
exploringjs.com/tackling-ts/ch

EDIT: Key point: It’s tricky to return a subtype of Incrementor (because of excess props). The code is just a toy example, with flaws.

exploringjs.comTyping objects • Tackling TypeScript

@rauschma I might have initially missed the point...

The chalenge is to use the factory pattern with pseudo-private fields through type shenanigans ?

@rauschma Why not use the closure scope for private fields as you'd do in plain JS ?

...

Replying to myself : I guess it can make figuring things out with the debugger more ergonomic. Do you have other reasons ?

@pygy I want to illustrate the point I made in the other post—via a toy example.

@rauschma Sorry for the noise, I'm reading my TL from the top (defaut behavior on mamot.fr), I've yet to scroll that deep...

@pygy I wouldn’t say shenanigans: We need a factory for objects of a given type. But it returns an object that is a subtype. Due to how TS handles excess properties of literals (*not* objects coming from variables), we get errors.