mgravell (64) [Avatar] Offline
#1
[from "ch7" version]

§5.5.7
> (guidelines)
I was going to say that it might not be immediately obvious that the "escape" bullet includes passing the delegate onwards - in particular to ISynchronizeInvoke.BeginInvoke; this doesn't return the delegate nor start a thread, but can cause mahyem if the delegate updates variables... but it may be beyond the scope of the book (not really a /language/ feature...)?

§6.2.2
> so much as the timing.
Is it realling "timing"? or just sequence of events?

§6
> (other uses)
just an aside; one use if iterators that I find quite useful is for creating data pipelines... you can craft a simple method that connects to a database using i.e. IDataReader, and yields each completed row (as an entity). This allows a higher layer (with no knowledge of the back-end) to consume the same DAL methods to either build an in-memory model simple by new List<T>(feed), or to loop over the data more efficiently (perhaps streaming to a file or response) using foreach. Very versatile. The iterators finally block would deal with closing down the connection etc. Of course, maybe LINQ reduces the beneift of this slightly.

§6.4
> Concurrency and Coordination Runtime
A mental prompt; cheers. That is what I was referring to in my §3.5.3 feedback ("Perhaps a future version .NET will have such facilities."). The Dispatcher/DispatcherQueue classes do (as far as I can tell) precisely this.

Only a few pages left; very much looking forward to the next MEAP drop ;-p

Regards,

Marc
jon.skeet (448) [Avatar] Offline
#2
Re: §5.5.7 thru §7.1.2
> [from "ch7" version]
>
> §5.5.7
> > (guidelines)
> I was going to say that it might not be immediately
> obvious that the "escape" bullet includes passing the
> delegate onwards - in particular to
> ISynchronizeInvoke.BeginInvoke; this doesn't return
> the delegate nor start a thread, but can cause mahyem
> if the delegate updates variables... but it may be
> beyond the scope of the book (not really a /language/
> feature...)?

Mmm... I think so. I think I'd rather stay clear on the fundamentals than go into too many details.

> §6.2.2
> > so much as the timing.
> Is it realling "timing"? or just sequence of events?

Sequence of events is exactly the right phrase - except that it's confusing when we're talking about a sequence of numbers. I've modified it to "so much as the flow of the code" (with flow italicised). Does that make sense?

> §6
> > (other uses)
> just an aside; one use if iterators that I find quite
> useful is for creating data pipelines... you can
> craft a simple method that connects to a database
> using i.e. IDataReader, and yields each completed row
> (as an entity). This allows a higher layer (with no
> knowledge of the back-end) to consume the same DAL
> methods to either build an in-memory model simple by
> new List<T>(feed), or to loop over the data more
> efficiently (perhaps streaming to a file or response)
> using foreach. Very versatile. The iterators finally
> block would deal with closing down the connection
> etc. Of course, maybe LINQ reduces the beneift of
> this slightly.

Well, LINQ *is* a data pipeline effectively smilie I'll make a note and see if I can fit something in.

> §6.4
> > Concurrency and Coordination Runtime
> A mental prompt; cheers. That is what I was referring
> to in my §3.5.3 feedback ("Perhaps a future version
> .NET will have such facilities."smilie. The
> Dispatcher/DispatcherQueue classes do (as far as I
> can tell) precisely this.

I certainly wrote chapter 3 before ParallelFX was announced. I'm not sure whether it's worth mentioning there or not... (I don't think that CCR itself is going to be prominent, but hopefully most of it will be part of ParallelFX.)

> Only a few pages left; very much looking forward to
> the next MEAP drop ;-p

Cool - glad you're enjoying it, and thanks for all your work!

Jon
mgravell (64) [Avatar] Offline
#3
Re: §5.5.7 thru §7.1.2
> I'd rather stay clear on the fundamentals
Probably best. Would only add confusion ;-p

> so much as the flow of the code
It is clearer to me; I don't know if I'm just being picky - please do say if I'm hampering!

> Well, LINQ *is* a data pipeline effectively
Yes, I'm realizing the similarity now in fact; off topic, but having finished the ch7 drop I'm trying spend some time extending my LINQ work (have only really played with a few object expressions) - and it is very similar to this approach, so I imagine that the later chapters will cover all this beautifully!

> ParallelFX
I will add that to my list of things to read into...
jon.skeet (448) [Avatar] Offline
#4
Re: §5.5.7 thru §7.1.2
> > I'd rather stay clear on the fundamentals
> Probably best. Would only add confusion ;-p

Goodo.

> > so much as the flow of the code
> It is clearer to me; I don't know if I'm just being
> picky - please do say if I'm hampering!

"Too picky" is an oxymoron at this point smilie

> > Well, LINQ *is* a data pipeline effectively
> Yes, I'm realizing the similarity now in fact; off
> topic, but having finished the ch7 drop I'm trying
> spend some time extending my LINQ work (have only
> really played with a few object expressions) - and it
> is very similar to this approach, so I imagine that
> the later chapters will cover all this beautifully!

Well, they'll cover pipelines - but mentioning that iterator blocks can be a good LINQ data source wouldn't go amiss.

> > ParallelFX
> I will add that to my list of things to read into...

smilie There's not a lot to know at the moment - I'm waiting for a CTP to drop so I can put some actual code together.

Jon