Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



It’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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: