Errata 8
From APIDesign
(New page: Page 132: Implementation of ''Playback'' interface should be named ''MyPlaybackPrints'' instead of ''MyCallbackPrints''. Page 134: There should be ''append'' method mentioned (instead of ...) |
(→Page 132) |
||
| (2 intermediate revisions not shown.) | |||
| Line 1: | Line 1: | ||
| - | Page 132 | + | ==== [[Errata 8|Page 132]] ==== |
| - | + | Implementation of ''Playback'' interface should be named ''MyPlaybackPrints'' instead of ''MyCallbackPrints''. | |
| - | Page | + | ==== [[Errata 8|Page 134]] ==== |
| + | |||
| + | [[Yoshiki]] suggests to use ''is not well understood'' instead of ''not part of conventional wisdom'' as that is much clear to international speaker in the paragraph that talks why [[APIvsSPI|client/provider]] API separation is much more visible in [[C]] and very blur in [[Java]]: | ||
| + | |||
| + | In the case of [[C]], the amount of work to produce an [[SPI]], such as a callback, is enough to prevent a beginner from even trying it. Your knowledge has to grow significantly to attain a state where you can or need to design an [[SPI]]. However, in [[Java]] any declared method that is not private, final, or static is an invitation for someone to provide a callback and thus create an accidental [[SPI]]. Often programmers and teachers don’t clearly understand this. It’s not part of '''conventional wisdom''' (e.g. '''not well understood'''). Although Java books introduce public, nonstatic, and nonfinal methods in their first chapters, or at least as soon as they start talking about applets, they don’t provide proper warnings about all their consequences. Though that might be fine for simple development, when you start to design APIs, all the bad habits learned at the start come back to haunt you in the form of mistakes. | ||
| + | |||
| + | However the message remains the same: Make sure you separate [[APIvsSPI|client and provider APIs]] and [[ClarityOfTypes|clarify meaning of types]] in your API. | ||
| + | |||
| + | ==== [[Errata 8|Page 134]] ==== | ||
| + | |||
| + | There should be ''append'' method mentioned (instead of ''write'') in this sentence: "This is reasonable behavior for implementors because those who subclassed ''Writer'' have not implemented the new ''write'' method." | ||
| + | |||
| + | ==== [[Errata 8|Page 140]] ==== | ||
| + | |||
| + | While introducing code for separating API/SPI concerns, after saying "''Say the original version of Writer looked like the following:''", ''final Writer'''s code is shown with one of its methods being "create(''java.io.Writer'')", which implies java.io.Writer's pre-existence. | ||
I am guessing that that method is there for convenience, because otherwise all java.io.Writer's method bodies should have been copied over into an Impl implementation in order to be able to run the sample source code, but for clarity, that method should probably not appear in that paragraph (maybe just in the downloadable source code with comments in its header). | I am guessing that that method is there for convenience, because otherwise all java.io.Writer's method bodies should have been copied over into an Impl implementation in order to be able to run the sample source code, but for clarity, that method should probably not appear in that paragraph (maybe just in the downloadable source code with comments in its header). | ||
| + | |||
| + | True, the "create(''java.io.Writer'')" method is not really necessary. On the other hand it provides real world example of the API use, matching it to some API familiar to the user. It demonstrates that the new ''Writer'' is good enough replacement for the standard ''java.io.Writer''. It shows later that by evolving the SPI to understand ''CharSequence''s the delegation to ''java.io.Writer'' can be done much more easily. | ||
| + | |||
| + | --[[User:JaroslavTulach|JaroslavTulach]] 18:45, 31 July 2009 (UTC) | ||
Current revision
Contents |
Page 132
Implementation of Playback interface should be named MyPlaybackPrints instead of MyCallbackPrints.
Page 134
Yoshiki suggests to use is not well understood instead of not part of conventional wisdom as that is much clear to international speaker in the paragraph that talks why client/provider API separation is much more visible in C and very blur in Java:
In the case of C, the amount of work to produce an SPI, such as a callback, is enough to prevent a beginner from even trying it. Your knowledge has to grow significantly to attain a state where you can or need to design an SPI. However, in Java any declared method that is not private, final, or static is an invitation for someone to provide a callback and thus create an accidental SPI. Often programmers and teachers don’t clearly understand this. It’s not part of conventional wisdom (e.g. not well understood). Although Java books introduce public, nonstatic, and nonfinal methods in their first chapters, or at least as soon as they start talking about applets, they don’t provide proper warnings about all their consequences. Though that might be fine for simple development, when you start to design APIs, all the bad habits learned at the start come back to haunt you in the form of mistakes.
However the message remains the same: Make sure you separate client and provider APIs and clarify meaning of types in your API.
Page 134
There should be append method mentioned (instead of write) in this sentence: "This is reasonable behavior for implementors because those who subclassed Writer have not implemented the new write method."
Page 140
While introducing code for separating API/SPI concerns, after saying "Say the original version of Writer looked like the following:", final Writer's code is shown with one of its methods being "create(java.io.Writer)", which implies java.io.Writer's pre-existence. I am guessing that that method is there for convenience, because otherwise all java.io.Writer's method bodies should have been copied over into an Impl implementation in order to be able to run the sample source code, but for clarity, that method should probably not appear in that paragraph (maybe just in the downloadable source code with comments in its header).
True, the "create(java.io.Writer)" method is not really necessary. On the other hand it provides real world example of the API use, matching it to some API familiar to the user. It demonstrates that the new Writer is good enough replacement for the standard java.io.Writer. It shows later that by evolving the SPI to understand CharSequences the delegation to java.io.Writer can be done much more easily.
--JaroslavTulach 18:45, 31 July 2009 (UTC)
Follow
