|
|
Log in / Subscribe / Register

implementations, interfaces, mumble grumble

implementations, interfaces, mumble grumble

Posted Jul 9, 2014 13:22 UTC (Wed) by tomgj (guest, #50537)
Parent article: The volatile volatile ranges patch set

Thanks for the useful article.

May I humbly suggest that the word “implementation” should be used more conservatively than this, especially as it relates to API design and interface specifiication.

The article says “Implementations of the volatile range concept have experienced more than the usual amount of change”. Though this is true, the way it is worded risks confusing issues around interface and implementation. This is because (i) implementations of the concept have involved different interface designs (as nicely expounded upon in the article), with (ii) implementations of those interfaces also having been through change. It would be nice, in a world where even advanced developers often don’t understand the value of well-specified interfaces, if we could, for clarity, reserve the word “implementation” for the latter kind of thing, marked (ii) above.

This confusion also arises in a couple of other places. We have “Previous volatile range implementations, though, had the property that marking a range nonvolatile could fail partway through. That meant that the interface had to be able to return two values”, which is using the term implementation to talk about the interface, and “This implementation will deliver a SIGBUS signal in that situation”, which is also better described in terms of being an interface thing.

Later in the article, we have “If the implementation and interface are not right…”, and here the term is clearly being used in the type (ii) sense as defined above. But, having set up use of the term “implementation” to mean either “implementation of a concept (possibly involving different interfaces)”, and “implementation of an interface”, the confusion sewn earlier is here reaped again.

All this comes back to a phenomenon way too common in Linux development: hack something together that “works” locally, and whatever happens to be exposed on the outside when it’s “working” then becomes the “interface”. This is the wrong way round, leads to low quality interface design, and wasted effort.

The article does describe thought going into the interface design. But how much better off would we be if interface design were more widely thought of as being the preceding process to implementation, rather than something to come later if at all? This doesn’t stop interface specification and implementation being co-iterative: the experience of actually attempting the implementation will often feed back proposed changes to the interface spec. But viewing interface specification as the fundamentally “earlier” process would have huge benefits. Most Linux-originated APIs are a wreck — here is part of the reason.


to post comments


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds