Errata 11

From APIDesign

Revision as of 16:22, 14 February 2014 by JaroslavTulach (Talk | contribs)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

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).

Personal tools
buy