Talk:Separate APIs for Clients and Providers
From APIDesign
(New page: '''Done: 9da22fb3cc94''' The name of the chapter doesn't make any sense to me. How about "Separating APIs into Client API's and Service Provider API's"? Page 120, para 2: "WinAmp" shoul...) |
m (Talk:Separate APIs for Client APIs and Support APIs moved to Talk:Separate APIs for Clients and Providers: Adjusting to the title in the printed version of the book) |
Current revision
Done: 9da22fb3cc94
The name of the chapter doesn't make any sense to me. How about "Separating APIs into Client API's and Service Provider API's"?
Page 120, para 2: "WinAmp" should be "Winamp".
--AndreiBadea 13:22, 8 April 2008 (UTC)
Done: 4b040ec30843
Page 121: xmms_register_playback should take a (void)(*f)(char*) parameter (note the order of * and f). Moreover, the parentheses around void are superfluous.
Page 121, para -1: "call back" should perhaps be "callback".
--AndreiBadea 13:29, 8 April 2008 (UTC)
Done: cc4e959ec9de
Page 124, CountingWriter code example: @author tag probably not needed.
Page 126, code example: convertChar is a very bad name for the function -- it doesn't hint what the method does. Suggest calling rot13 instead of convertChar. You don't even need to list the code for rot13, a comment above the line where you call it should be enough for those readers who haven't encountered this algorithm yet.
Page 126, para -2: typo in BufferedReader.writer(String).
Page 127, code example: no apparent reason for the (csq != null && csq.length() < 1024). Yarda says it is because the BufferedWriter needs to buffer. In that case, perhaps moving the test to a shouldBuffer method or similar would be more transparent.
Page 129: weird formatting of write(char cbuf[]) and write(String str). This code example also uses arr and cbuff interchangeably, please consider consistently using a single name.
The example is perhaps a bit too long. Considering that you made it up, are all those overloaded write methods necessary?
Page 131: the parameter of create(ImplSeq impl) should be named seq for the sake of consistency.
--AndreiBadea 13:46, 8 April 2008 (UTC)
- Pages 129-132: Code samples were long and was difficult to know exactly what I should be looking for.
--TomWheeler Sat Apr 12 19:13:37 CDT 2008
Done: 70c0c4836a28
Page 134, para -2: "masterfs" will only make sense to NetBeans developers. Why not use "master filesystem" instead?
--AndreiBadea 13:52, 8 April 2008 (UTC)
Page 133: The first sentence is a very concise summary of the difference between API and SPI. You should consider also using it in the previous section when you introduce the concept.
Page 133: Kirk Knoernschild "Java Design" book does an excellent job of explaining the importance of packages in Java. Maybe you should reference it here, since you touch on the same subject.
--TomWheeler Sat Apr 12 19:13:37 CDT 2008