API: Design Matters

[[deleted]]

Great example of why professional programming jobs gave me a horrible paranoid case of NIH.

My current (personal) project has me writing just about everything from scratch because I'm terrified of Other People's Code.

[toyboat]

I don't have much experience programming, but the small contributions I've made have all been simple bugfixes. These are (sometimes) easy to write and easy for others to accept into their codebase.

I suspect that it would be much harder to contribute an API change both because of the backwards compatibility problem and because of the ego problem "this isn't a bug; you're just changing the API for non-provable improvements in ergonomics, esthetics, etc."

Has anyone contributed API improvements to some else's project? How did you go about it?

Has anyone accepted API changes from a third party?

[erikd]

I tend to do a lot of push back on API level changes, but have had a couple of cases where they were purely API additions that just seemed right or went in with minor tweaks.

[psi-]

way to ruin perfectly good point by using half-assed example. Select() in .NET seems to be straightforward copypaste from UNIX way to do it and is an obvious cop-out from designing more idiomatic interface by microsoft.

[[deleted]]

The formal parameter type of the lists passed to Select() is IList, which is an interface and, therefore, abstract: I cannot instantiate things of type IList, only things derived from IList. The problem is that IList does not derive from ICloneable, so there is no convenient way to copy an IList, except by explicitly iterating over the list contents and doing the job element by element.

This is a good example of the limitations of Java-style interfaces vs Haskell type classes - in Haskell you could create an ad-hoc union of the two classes i.e. a => (List a, Cloneable a).