EvenMoreLinq reviews

[Johannes Rudolph]

Hi,

I have just started working on reviewing some of the EvenMoreLinq Operators.

Based on this, I have some questions on which I am asking for an "authority" opinion.

Most of the Operators yield an IEnumerable instead of returning a fully evaluated list. Can we agree on calling this lazy-evaluation?

Most of the trunk code (and the linq implementation too) sticks to the convention of documenting this behavior. Should this convention be enforced on the new code? On the other hand, we could change the convention into the opposite and enforce documentation on immediate execution operators.

A lot of documentation has missing punctuation (full sentences without a . at the end). I know it's nitpicking but it can be easily (and automatic for that matter) fixed. This makes generated, in the future maybe external, docs more readable.

What's your take on this?

Kind regards,

Johannes

[Jon Skeet]

On 31 January 2010 20:40, Johannes Rudolph <jojo.r...@googlemail.com> wrote:

I have just started working on reviewing some of the EvenMoreLinq Operators.

Based on this, I have some questions on which I am asking for an "authority" opinion.

Most of the Operators yield an IEnumerable instead of returning a fully evaluated list. Can we agree on calling this lazy-evaluation?

Only if it's genuinely lazy :) It could return an IEnumerable<T> implementation without using an iterator block, and thus be eager.

 

Most of the trunk code (and the linq implementation too) sticks to the convention of documenting this behavior. Should this convention be enforced on the new code? On the other hand, we could change the convention into the opposite and enforce documentation on immediate execution operators.

Document it either way. Operators should (IMO) document:

• Whether they're lazy or eager
• Whether they buffer data (like Reverse) or stream it (like Select) or something in between (like Join, where the inner sequence is buffered but the outer sequence is streamed)
• Whether they take advantage of any optimisations (like Count() being able to avoid iterating if it's called on an ICollection)

A lot of documentation has missing punctuation (full sentences without a . at the end). I know it's nitpicking but it can be easily (and automatic for that matter) fixed. This makes generated, in the future maybe external, docs more readable.

What's your take on this?

I tend to put a . at the end if it's genuinely a full sentence, but not if it's only a fragment. For example, often when documenting a parameter or type parameter, you don't have a full sentence, you just have something like "the type of the elements in the sequence" - so I don't have a period. That's a habit from book authoring though (it's what you do in bulleted lists), and I don't know how others feel about applying it here.

Jon

[Johannes Rudolph]

Hi Jon,

Thank you for your feedback. I think you're suggestions are perfectly reasonable. I have published my review results on Partition() and started on RunLengthEncode() and Slice().

It's my first code review so please be patient with me if I suggested things worse than before :-)

Johannes

--
You received this message because you are subscribed to the Google Groups "MoreLINQ Developers" group.
To post to this group, send email to moreli...@googlegroups.com.
To unsubscribe from this group, send email to morelinq-dev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/morelinq-dev?hl=en.