Errata 11
From APIDesign
JaroslavTulach (Talk | contribs)
(New page: ===== Page 193 ===== Yoshiki observed that the following paragraph should use ''return values '' instead of ''return types'': An unsynchronized API is usually only handy for objects ...)
Next diff →
Current revision
Contents |
Page 193
Yoshiki observed that the following paragraph should use return values instead of return types:
An unsynchronized API is usually only handy for objects that are not shared. These are objects that your calling code creates and keeps private. It's fine not to synchronize anything and to delegate access control into the hands of the API's user. An example is the java.util Collections API, and it seems to work well there. The client code only needs to be aware of the need to keep objects private and not to leak them out via method return values or calls.
Just don't let your objects escape from your local thread state!
Page 195
It would be nice for the samples to have a bit wider context. They may be too hard to understand.
Page 203
Page 203 and 207: Class names R and H are bit misleading as a single letter identifiers are usually used as type parameter names.
Page 209
Page 209: The text is referring to the side note. You should read the side note first.
Page 214
Page 214: Example of controlFlow is bit harder to understand as it is using regular expression for two lines of log without further explanation. In fact it is just manifestation of such possibility (not required for the sample in order to work).
Follow
