▲ | seanmcdirmid 5 hours ago | ||||||||||||||||
TS doesn’t really. TS simply treats private fields as public ones when it comes to structural type checks. TS is unsound anyways, so not providing hard guarantees about field access safety is right up its alley. More to the point, if you specify a class type with private fields as a requirement, whatever you plug into that requirement has to have those private fields, they are part of the type’s public signature. To get where structural type systems fall down, think about a bad case is when dealing with native state and you have a private long field with a pointer hiding in it used in native calls. Any “type” that provides that long will fit the type, leading to seg faults. A nominal type system allows you to make assurances behind the class name. Anyways, this was a big deal in the late 90s, eg see opaque types https://en.wikipedia.org/wiki/Opaque_data_type. | |||||||||||||||||
▲ | b_e_n_t_o_n 4 hours ago | parent [-] | ||||||||||||||||
Typescript had to support JS's quirks... :/
Which is why you'd generally use interfaces, either declared or inline.In the pointer example, if the long field is private then it's not part of the public interface and you shouldn't run into that issue no? | |||||||||||||||||
|