API Design
in [General Programming]
|
Prev: Water plant design | Design Build | Water plant construction
Next: Two programs with same logic
From: Thad Smith on 19 Dec 2009 13:36 jacob navia wrote: > http://cacm.acm.org/magazines/2009/5/24646-api-design-matters/fulltext > > > Communications of the ACM rarely bring something practical. > This is a good exception. > > It is a good article about API design, and the problems of bad APIs. Agreed. I plan to distribute the link to others at work. It makes explicit the policy-free vs. policy-rich trade-off, which is a useful insight for me. Good design of low-level functions has a multiplying effect on application code. Followups set to comp.programming. -- Thad
From: William Ahern on 19 Dec 2009 14:56 Thad Smith <ThadSmith(a)acm.org> wrote: > jacob navia wrote: > > http://cacm.acm.org/magazines/2009/5/24646-api-design-matters/fulltext > > > > > > Communications of the ACM rarely bring something practical. > > This is a good exception. > > > > It is a good article about API design, and the problems of bad APIs. > Agreed. I plan to distribute the link to others at work. It makes A good API emerges from iteration. You really can't know how to make a new API work for you until you've used it in various situations. Tweak, use, tweak use. Sometimes after two or three iterations you have a really solid design, sometimes you need more. A couple of the authors suggestions in that paper reflect this dilemmea, with the vain suggestions about documentation and separating the caller from implementor. Iteration is extremely hard to accomplish in a commercial environment with other engineers because re-writing code is usually frowned upon, especially once others have begun using the interface. (Thus if you separate caller from implementor you'll never get the opportunity to change the API; and it's foolish to think the first try will be even remotely optimal.) This is why C++, Java, and C# are so popular commercially. For one thing, if you implement a canonical design pattern, no matter how unwieldy or overkill, nobody will object. Second, these interfaces can just be papered over with super/sub classing on an ad hoc basis. This is also why the claims of improved modularity in these OOP languages are baseless, because in practice cross-dependencies grow very quickly. One strategy is to write mock-up software in, say, Perl. The standard forms in Perl reduce to C code rather well, as long as you're not using too many modules. And of course design iteration in Perl is much faster than in C. The interesting thing about C and design patterns is that though you can obviously implement a design pattern in C, it's very difficult to implement it in a universal fashion. It will almost always be closely bound to the particular context. And this, I propose, is good thing!
From: James Harris on 19 Dec 2009 16:26 On 17 Dec, 17:06, jacob navia <ja...(a)nospam.org> wrote: > http://cacm.acm.org/magazines/2009/5/24646-api-design-matters/fulltext > > Communications of the ACM rarely bring something practical. > This is a good exception. > > It is a good article about API design, and the problems of bad APIs. It is a good article though I'd take exception to his criticisms of the C select function. If it were to do as he suggests and return a number of fds without overwriting the input fd set it would have to return newly allocated memory which it would be left to the caller to free. This could be done but it would be unusual for C functions wouldn't it? IIRC some of the string functions return new objects but most other C functions seem to go to lengths to avoid doing so. - in anticipation that someone will correct me if my impression is wrong.... James
From: Ian Collins on 19 Dec 2009 16:59 James Harris wrote: > On 17 Dec, 17:06, jacob navia <ja...(a)nospam.org> wrote: >> http://cacm.acm.org/magazines/2009/5/24646-api-design-matters/fulltext >> >> Communications of the ACM rarely bring something practical. >> This is a good exception. >> >> It is a good article about API design, and the problems of bad APIs. > > It is a good article though I'd take exception to his criticisms of > the C select function. If it were to do as he suggests and return a > number of fds without overwriting the input fd set it would have to > return newly allocated memory which it would be left to the caller to > free. This could be done but it would be unusual for C functions > wouldn't it? IIRC some of the string functions return new objects but > most other C functions seem to go to lengths to avoid doing so. The Unix select function is pretty clunky, but at least it does provide a clearly documented means for passing an indefinite timeout. Note that Unix also provides the poll function, which provides a cleaner interface that preserves the original socket lists. If I were inventing a new framework, I'd use poll rather than select. See http://opengroup.org/onlinepubs/007908799/xsh/poll.html -- Ian Collins
From: Pascal J. Bourguignon on 19 Dec 2009 17:03
James Harris <james.harris.1(a)googlemail.com> writes: > On 17 Dec, 17:06, jacob navia <ja...(a)nospam.org> wrote: >> http://cacm.acm.org/magazines/2009/5/24646-api-design-matters/fulltext >> >> Communications �of the ACM rarely bring something practical. >> This is a good exception. >> >> It is a good article about API design, and the problems of bad APIs. > > It is a good article though I'd take exception to his criticisms of > the C select function. If it were to do as he suggests and return a > number of fds without overwriting the input fd set it would have to > return newly allocated memory which it would be left to the caller to > free. This could be done but it would be unusual for C functions > wouldn't it? IIRC some of the string functions return new objects but > most other C functions seem to go to lengths to avoid doing so. > > - in anticipation that someone will correct me if my impression is > wrong.... You could pass it two vectors, one with the fds to select, and one with space for the results (times three of course). Or you could use a garbage collector, but then select couldn't be a syscall anymore. -- __Pascal Bourguignon__ http://www.informatimago.com/ "Specifications are for the weak and timid!" |