5 ms·
Yes, they have their reasons. They always do, tradeoff etc, I know. It doesn't change the fact that ie. adding private member is breaking change in your librar
by mirekrusin 3y ago
Yes, they have their reasons. They always do, tradeoff etc, I know.
It doesn't change the fact that ie. adding private member is breaking change in your library which is kind of funny (until it's not funny of course).
Also stuff like:
class Foo { private foo = 1 }
class Bar {}
const a: Bar = new Foo
...typechecks so that's it for nominality.
It's all ifs all the way down.
- eyelidlessness 3y agoIt’s only a breaking change if you’ve been using a class to stand in for an interface (happens to the best of us I’m sure!). You can still avoid it being one after the fact by introducing a non-breaking interface consistent with what you were already accepting/expecting. And yeah, I’m not a fan of that class instance assignability case. Not to make excuses for it, but I have other reasons I generally prefer to expose interfaces (distinct from classes, even if they’re identical in shape and even have the same internal purpose) at most API boundaries; avoiding that particular footgun just turns out to be a nice happy side effect of the preference.