Documentation issues

[Ivan]

Hi,


1) On page 87 interface RadioClock extends Radio and Clock interfaces. On the next page there is an inheritance diagram where RadioClock inherits from Radio and AlarmClock. So where is a "typo", in diagram or in interface definition?

2) On page 90 you introduce ProxyStore interface. In the next chapter "Null Proxies" you are referring to the ObjectStore interface. Probably, you wanted to refer to ProxyStore interface instead. (because ObjectStore was not defined at all.)

Ivan

[michi]

Originally posted by Ivan
Hi,


1) On page 87 interface RadioClock extends Radio and Clock interfaces. On the next page there is an inheritance diagram where RadioClock inherits from Radio and AlarmClock. So where is a "typo", in diagram or in interface definition?

2) On page 90 you introduce ProxyStore interface. In the next chapter "Null Proxies" you are referring to the ObjectStore interface. Probably, you wanted to refer to ProxyStore interface instead. (because ObjectStore was not defined at all.)

Ivan

Thanks muchly for pointing this out! Your are right -- Figure 4.5 should just show inheritance from Radio and Clock, not AlarmClock. On page 90, the two mentions ObjectStore should read ProxyStore.

I've fixed this for the next version.

Thanks,

Michi.

[Ivan]

Chapters 4.9.5/4.9.7: on both pages 102 and 103 the definition of class Operand does not extend class Node, but it should.

Ivan

[andreynech]

Hi,

On page 133 the second bulleted paragraph: "... it is NOT impossible for a process to receive... ". Should not it be: "...it is impossible..." ?

Thanks,
Andrey.

[michi]

Thanks muchly guys, this will be corrected in the next published version.

And we really appreciate all the feedback and bug reports so, please, keep them coming!

One of the problems when writing a book is that, as the author, after a while, it's very difficult to actually read the stuff as if I'd never read it before. As a result, I keep skipping over my own mistakes because I read what I meant to say, not what is actually there. So, the independent review by people who read the text with a fresh mind is really valuable!

Thanks,

Michi.

[Ivan]

On pages 321 and 322, in put() method (_q.size == 1) should be (_q.size() == 1)

Ivan

[michi]

Originally posted by Ivan
On pages 321 and 322, in put() method (_q.size == 1) should be (_q.size() == 1)

Ivan

Ivan, thanks again! At the rate you are going, we will have to give you a medal!

Cheers,

Michi.

[Ivan]

Thanks Michi, gold one please ;-)

On page 328, 4th line from bottom, "is" should be "its".

I feel a bit uncomfortable to send such a correction

Ivan

P.S. Doc for Ice-1.0.1

[michi]

Originally posted by Ivan
[b]Thanks Michi, gold one please ;-)

OK, we'll make it a gold one ;-)

On page 328, 4th line from bottom, "is" should be "its".

I feel a bit uncomfortable to send such a correction

No, not at all -- if it's wrong, it's wrong and needs to be fixed. Thanks!

Cheers,

Michi.

[Ivan]

As we agreed earlier AlarmClock interface should not be shown on the figure 4.5.

Then it should not be shown also on the figure 4.7!

And thus you have to exclude "::AlarmClock" from the last sentence in the chapter 14.13.

Ivan

[dhalbert]

I've been reading the Ice Manual over the past few days, and it looks great! My comprehension of much of the material came easily, perhaps because I could relate and compare it to CORBA, but when I got to the IcePack chapter I slowed down. Eventually I did get an "Aha!" moment, but I think some diagrams showing the relationships between the objects mentioned in that chapter and the queries and datflow would have speeded up my understanding.

Thanks,
Dan

[mes]

Dan,

I agree that the IcePack chapter is rather dense; it could definitely benefit from a few diagrams.

Thanks for the suggestion.
- Mark

[mick]

Here's a bunch of minor doco improvements. All but the last are simply grammatical changes.

N.B. I pondered whether to post this here or to email icebook@zeroc.com as the book suggests, but it seems like people are using this thread for the purpose and by posting publicly it saves on duplication of effort.

Page 14: "are important because the guarantee" should be "are important because THEY guarantee"
Page 15: "so at-most-semantics" should be "so at-most-ONCE-semantics"
Page 24: "IcePack allows you register servers for automatic start-up:" should be "IcePack allows you TO register servers for automatic start-up:"
Page 29: "it is possible determine" should be "it is possible TO determine"
Page 60: "Language mappings define rules for dealing such identifiers." should be "Language mappings define rules for dealing WITH such identifiers."
Page 63: "See BIBREF for an good treatment of the topic." should be "See BIBREF for A good treatment of the topic."
Page 63: "or use an empty string represent the idea of a null string." should be "or use an empty string TO represent the idea of a null string."
Page 66: "There a number of options of dealing with this situation:" should be "There ARE a number of options FOR dealing with this situation:"
Page 67: "Strings come with their on in-built sentinel value" should be "Strings come with their OWN in-built sentinel value"
Page 69: "sequences of with elements of integral type or string" should be "sequences with elements of integral type or string"
Page 72: "This definition defines a interface type called Clock" should be "This definition defines AN interface type called Clock"
Page 75: "A common example of this an iterator" should be ""A common example of this IS an iterator"
Page 86: "(at least for statically type-safe languages, such as C++ and Java)." should say "(at least for statically TYPED languages, such as C++ and Java)."

nb. note that C++ is statically typed, but is not type safe.


cheers,
mick

[michi]

Originally posted by Ivan
As we agreed earlier AlarmClock interface should not be shown on the figure 4.5.

Then it should not be shown also on the figure 4.7!

And thus you have to exclude "::AlarmClock" from the last sentence in the chapter 14.13.

Ivan

OK, fixed. But I fixed it by putting back the original AlarmClock (which was the idea all along). So, in Figure 4.5, AlarmClock should have been shown all along. The problem really was with the code example on page 87 -- RadioClock should inherit from Radio and AlarmClock, instead of Radio and Clock.

Cheers,

Michi.

[michi]

Originally posted by mick
Here's a bunch of minor doco improvements. All but the last are simply grammatical changes.

N.B. I pondered whether to post this here or to email icebook@zeroc.com as the book suggests, but it seems like people are using this thread for the purpose and by posting publicly it saves on duplication of effort.

Agreed, here is just as good as via e-mail -- whatever you prefer.

Thanks for all the detailed fixes -- I've corrected them for the next version.

Page 86: "(at least for statically type-safe languages, such as C++ and Java)." should say "(at least for statically TYPED languages, such as C++ and Java)."

nb. note that C++ is statically typed, but is not type safe.

Hmmm... I'm not sure I get your meaning. C++ is statically type safe because the compiler enforces at compile time that constructs make sense as far as their types are concerned. For example, the compiler won't let me call a method on a derived type via a pointer to a base type. In contrast, languages such as SmallTalk are not statically type safe: I only find out at run time if an object actually provides the method I'm calling at it.

So, is there any difference in meaning between "statically typed" and "statically type safe?"

Cheers,

Michi.


cheers,
mick [/b][/quote]