mgravell (64) [Avatar] Offline
(I'm trying to limit the depth of each chain to avoid confusion)

> Perhaps a future version .NET will have such facilities.
I remember reading some MS material on just such a set of libraries - offering custom thread-pools etc for massively async models. I can't /for the life of me/ remember which set of libs, though!


3.6.1 (valid/invalid example)
There's an odd combination of bold/regular and typeface in this panel. Maybe it means something that I am missing? Also - you refer to "second line", but it isn't clear (without reading ahead to what the problem is) whether this is "line of code" or "line in the panel"; perhaps simply "on the second line of code." or similar?


Footnote 32
> Don’t get me started.
I thought you already did in 1.2? ;-p (not a criticism; we have to laugh at this duality...)


covariance / contravariance
not helpful if you ar etrying to reduce, but it occurs that one of the common generic questions on forums etc boils down to turning
SomeMethod(IEnumerable<BaseClassOrInterface> items) {...}
SomeMethod<T>(IEnumerable<T> items) where T : BaseClassOrInterface {...}

It just feels like such a core concept (and one that that isn't necessarily obvious at first [I remember being astounded when I first saw it, then feeling rather foolish])that it warrants a mention?
mgravell (64) [Avatar] Offline
Re: Misc thoughts part 3
> which is equivalent to ###use### java.lang.Object for each


> ###Remember that that also means### you can’t
> use another nullable type as the argument
I'm unclear whether this means "recall given what we've covered", or "you should take note". I parsed it as "recall", but this argument doesn't follow from the chapters before. I agree that what you say is true (can't use int? as a value-type condition), but it is surely a special case?

It makes sense you interpret it as the "take note" case, but still the "that that also means" sounds like "is therefore implied by", which isn't the case (excuse the lazy code):
struct Test<T> where T : struct { public T Field;}
static class Program {
static void Main() {
Test<int> a = new Test<int>();
a.Field = 17;
Test<Test><int>> b = new Test<Test><int>>();
b.Field = a;
Test<Test><Test><int>>> c = new Test<Test><Test><int>>>();
c.Field = b;


> ###Again###, this always results in an instance where HasValue returns true.
When was the prior, for which this is an "again"?
jon.skeet (448) [Avatar] Offline
Re: Misc thoughts part 3
3.5.3: I expect ParallelFX may well have this. I'll write a comment to check.

3.6.1:Hmm. Not sure why the bold bit is in MEAP. It's not in my copy.

3.6.1: Second line - it's the second line of code in each side of the table. (It may well not be a table eventually, btw.) In other words, it's the "bases[0] = new Base():" and the "bases.Add(new Base());" lines.

Footnote 32: Yes indeed. Would it be funnier as "Don't get me started about versioning again"? Or is it better to be brief?

Turning generic parameters into generic methods: I'll see what I can do. It's a good point. I'm almost certainly going to cut chapter 3 down in size a bit anyway, so I'll look at that whole section and whether it can be turned around a bit. Covariance/contravariance is a pain to discuss, unfortunately smilie
jon.skeet (448) [Avatar] Offline
Re: Misc thoughts part 3
3.6.5: Fixed, thanks.

4.2.1: Yes, that does indeed mean "recall"; it's sort of covered in 3.3.1, in that I say that the ": struct" constraint excludes nullable types. It's a special case, but one worth mentioning (as otherwise people may well wonder if they can have Nullable<Nullable><int>>smilie. Perhaps I should give it less prominence though?

It *is* implied by "it has the value type constraint" IMO. Test<Test><Test><Test><int>>>> etc works because none of them is nullable. I think I may be missing your point...

4.2.1: I've just removed the "again". It was probably there from when things were in a different order.
mgravell (64) [Avatar] Offline
Re: Misc thoughts part 3
> ParallelFX
Not familiar with this, but I don't think that was the same one, but projects merge and diverge, so it is hard to tell...

> second line
yeh, I figured it out fine - it just wasn't immediately obvious. But it works...

> footnote 32
not sure; but at least if you reference "again" you are acknowledging that the other section exists... On first read, I actually wondered if you'd written this section first, then added the earlier (versioning) code... maybe it doesn't really matter...

> covariance / contravariance
I've been working with generics in c# for several years, and I would consider myself competent in their usage; but even with that knowledge, reading about specific of covariance and contravariance is not for the faint hearted. Writing about it must be a lot harder again.
Actually, in the book as a whole (that I have read so far) I'm pleasantly surprised (given the subject) at how approachable the writing style is, with enough humour to help keep the interest, but not too much as to be irritating. And still, the content is informative, helpful, accurate and with a stated aim.
However, there is a page-or-so in the co[ntra]variance section that (given the style elsewhere) catches you off guard, where I found myself having to read quite slowly to digest it.
But co[ntra]variance *is* difficult, so I don't know how much you can do about this... perhaps just some kind of warning to help prepare the reader?

>pain to discuss
I don't envy your position; critical to the subject, and very hard to do justice in a similar way to the rest of the book... I can't put my finger on it (maybe a few re-reads will help), but I can't help thinking *something* in this section could be just a bit clearer. It might even be a tiny change. I think I've switched into user-mode: a complete failure to articulate what the problem might be... sorry...

I mean the above in a completely positive way; if I can tell you where something is sticky you might be able to tweak it...

jon.skeet (448) [Avatar] Offline
Re: Misc thoughts part 3
ParallelFX: It's what Joe Duffy is working on now. I'm hoping it'll take in a lot of the CCR stuff as well.

Footnote 32: It was written in chapter order in fact, but I just didn't worry about it smilie

Writing style re covariance etc: Most of the C# 2 stuff isn't too dense. Some of the C# 3 stuff is harder though, particularly near the end of chapter 9, at the moment. You'll see in the next MEAP batch, I guess smilie I'd like to keep it light and easy everywhere, of course, but some stuff is just fundamentally relatively tricky. The funny thing is reading the later chapters and seeing how much I have to assume the reader is now comfortable with.

Lack of clarity of the covariance section: You're absolutely right, and it's something I've already struggled with. I suspect it's more rewrite territory than tweaking, just to give me a fresh canvas. Any pointers (such as the one you've already given) are *very* helpful though.
mgravell (64) [Avatar] Offline
Re: Misc thoughts part 3
> in 3.3.1, in that I say that the...
> It *is* implied by "it has the value type constraint" ...
My bad; having just fought co[ntra]variance, I had forgotten this subtlety of the value-type constraint from 36 pages ago (MEAP pages; who knows how that will translate at type-setting...).
It also just goes to show you that I don't use Nullable<T> very often ;-p

You are 100% correct, yet I wonder how many other readers (especially those who might be new to some of the concepts) might also miss this point?

jon.skeet (448) [Avatar] Offline
Re: Misc thoughts part 3
Value type constraint: Yup. I'll point back to the relevant passage and use slightly more forgiving language than "Remember" which suggests the reader is foolish if they don't smilie