undefined | Better HN

0 pointsscratcheee1y ago0 comments

That argument works pretty well for any bad api design (assuming sufficient documentation somewhere).

Yet I assume we can agree that regardless of how you can work around bad apis, good api design that prevents misuse is always better.

The safety measures have to stop somewhere of course (short of an api that is a single function which does exactly the thing you want without inputs or outputs, which seems unlikely), but extending type safety to interfaces does not seem like a step too far.

0 comments

jayd161y ago

Another aspect of the issue is to consider the asymmetric nature of knowledge of the API author and the API consumer.

When one authors a type in a language like C# they must predict how that type will be used and what interfaces the author promises the type can be.

The API consumer might be unfamiliar with the types in an API at first, but ultimately they will know more about how they want to use the type and what additional contracts they think the type fulfills.

As it is, this knowledge is only useful when inheriting a type. There is no facility to "vouch" for a type in C#, currently. In Go structural typing fulfills this.

I think Extension Interfaces is the best of both worlds.

j / k navigate · click thread line to collapse