Download Reference Manual
The Developer's Library for D
About Wiki Forums Source Search Contact

Add notes here (with your initials)

Overlapping Areas

  • kb: this appears to have been resolved (to me)

Chapter 1

  • kb: formatting looks a bit odd in places
  • kb: D is introduced, but Tango gets little love
  • lii: Concur about Tango not getting enough attention
  • lii: I think modules are discussed too deeply for an introductory chapter, perhaps especially the protection attribute stuff.
  • lii: you/we feels better to me now
  • mp: ditto on the module discussion. Should be pared down to the bare essentials since it's discussed in detail in ch. 3.
  • mp: for completeness, DSSS should be mentioned in the compilation tools section

Chapter 2

  • kb: tables look kinda' strange, though Mike tells me it's all kosher
  • mp: need to add a section on exceptions and scope statements
  • mp: need to mention the basic operators and the special floating point operators
  • mp: several tweaks need to be made to some of the topics which are discussed later on, particularly those Sean covers in Chp. 4. There's some bit of overlap there, but I'm not quite sure yet which chapter should get the tweaking. Perhaps some of both.
  • lii: nothing :)

Chapter 3

  • kb: "Introducing Modules" should be renamed to "Modules Revisited" or "D Modules" (or just "Modules") since they've already been introduced :)
  • kb: I think the titles and subtitles here need to be shortened. The idea is good, but some titles span two lines, and all of the other chapters (except ch6) have short titles. For example: "Operator Overloading - Letting Your Types Leverage The Language" ... should probably just be "Operator Overloading"
  • kb: for me this is still a tough one to read; notably more difficult than any other chapter. Larsivi has at least twice the work here, since English is supposed to be native for the rest of us :)
  • lii: Agree about extended headings, especially as long as I've been the only one using them :)
  • lii: I don't want to use native language as an excuse, even if it probably has a bearing on certain aspects. I think the hard reading of this chapter is due to the rather large and abstract (and somewhat complex at times) subject matter being condensed into very few pages, not sure that is entirely fixable?
  • mp: the word 'method' is used quite a bit as 'way', 'means', or 'technique'. To avoid any potential of confusion, I think an appropriate synonym should be substituted in those cases and 'method' should be strictly used to refer to D methods.
  • mp: there needs to be some mention on what is legal in both structs and classes. It should be made clear in the relevant sections on class discussion (i.e., this is also legal in structs)
  • mp: there needs to be a clearer distinction between the Property Syntax section and the Class Properties section, to drive home the point that the former is on custom properties. I would rename the Property Syntax section to Custom Properties and move it to immediately follow Class Properties. As far as I can see, there is no previous discussion of custom properties.

Chapter 4

  • kb: Stdout is used in all chapters except this one, which used put() instead. I think this should be made consistent
  • kb: all other chapters make use of the inline code style to make code references. This chapter uses italics instead, which I suspect should be changed to be more consistent overall.
  • sk: Both of these issues have long since been fixed in my copy of the chapter.
  • mp: as per my comment on chp 2, there's some bit of overlap here with previous chapters. Obviously it can't really be avoided. I have a feeling that, in some cases, it may make sense to cut down the discussion of a topic in a prior chapter and expand on it here.

Chapter 5

  • kb: makes reference to a number of keywords that have not been introduced or discussed: new terminology without explanation. Perhaps a sidebar here and there would work?
  • kb: many examples with no listing of the expected output. This made the chapter harder to follow than it could be.

Chapter 6

  • kb: the main title "Text Processing - Strings Attached" stands out from all other main titles. I suggest dropping the catchy "Strings Attached", particularly since there should not be any attached. Same with "Utilities - Common Operations" since there really should not be any need to explain the heading/title to the reader. Basically, any title/heading with a '-' in it should perhaps be reviewed? Same concern as chapter 3
  • lii: Still agree on headings.

Chapter 7

  • kb: first set of pages needs to be dumped and rewritten, based around streams instead. Perhaps add conduit/buffer/etc as sidebars
  • lii: very good chapter - easy to read - explains concepts and functionality very well
  • lii: the section title style (the one that isn't a real header) isn't used elsewhere as far as I have seen, maybe h3 should be used instead?
  • lii: the functionality discussed in both chapter 6 and 7 (formatting and iterators) could probably be shorter? seems a bit like repetition - and it is only said at the end of those sections that you can also read about it in ch6.

Chapter 8

  • kb: thread examples use Stdout, which is (deliberately) not thread-safe. Use Trace in place of Stdout for these examples
  • lii: I believe "we" should be used instead of "I" - otherwise pretty perfect :)

Other Concerns

  • kb: I didn't see any coverage of 'scope' for simplified exception/finally. Perhaps add to chapter 2? Actually, I don't recall anything about try/catch/finally either
  • kb: Tango gets little attention until chapter 5. This may or may not be an issue
  • kb: no overview/intro to delegate or function keywords (which are referenced). Perhaps a sidebar, or add to chapter 2?
  • kb: no overview/intro to alias or pragma (which are referenced). Perhaps a sidebar in the relevant chapter?
  • kb: I'd really like to add an 'index' for tango, even a partial one
  • kb: seemed like everyone except myself managed to avoid mentioning toUtf8/16/32 in the context of toString. I'll remove my reference, but wanted to ensure we're all trying to avoid that one
  • lii: Paraphrasing Jason here; All examples should use Tango as long as at all possible. If not, some other near to real life example should be used. Foo/Bar/Wumpus to be avoided.

Overall thoughts

  • kb: I think it'll flow ok, given changes here and there. Will also send out typo-lists to folks.
  • kb: It's abundantly clear that Mike is the writer amongst us: his chapters stand out like beacons of light compared to the rest of them. Mike's chapters are a joy to read, while all the others (mine too) caused me to struggle or reread too often.
  • kb: Honestly feel that, after these immediate changes, we should turn over all chapters to one person who would make whatever edits they feel appropriate in order to improve things. I'd like that person to be Mike, but don't know if he has the time or inclination. I'd be willing to do it, if Mike couldn't, at the expense of quality.
  • kb: we don't have much time to turn these changes around, folks. This is our big chance to give Tango a huge boost, and may turn out to be the only book most of us ever write. Surely it's worth putting in the effort right now to make it really solid
  • lii: I agree with K, would be nice if Mike can do this.