I agree, very elegant. Never quite occurred to me to do caching in this way, but it does make sense. Definitely something I will have to consider in the future.

Personally, I don't really like linq syntactic sugar.

To me, this is just as clear, if not clearer:

queriesLookup.Values

.Select(agg => new QueryAggregationSnapshot

  {

      ...

  }

.Cast <iqueryaggregationsnapshot
.ToArray()

What I don't like is that it's a little difficult to debug. For example, if I wanted to know the value returned by Read() or by Write(), I would have to work quite hard.

When writing a public method such as this one, I often would assign the return values to variables and test the variables explicitly to facilitate debugging.

Lame...even gay; if you ask me. ;)

Too dense for my taste. Too many things happens at once, so I have a hard time figuring out what is going on.

@Sasha. Outside the function itself it shouldn't matter if the result cam from cache or was freshly created.

I don't know how you write your tests, but I hope you don't started testing cached in the GetReportSnapshot tests. As GetReportSnapshot depends on cached, it's safe to assume cached would work properly as that part is covered elsewhere.

Why would you give the GC a lot of work only so you can when you have a problem set a breakpoint? If you ever would encounter a problem in the GetReportSnapshot method, just add the intermediate (result) variable just for debugging. When you're done debugging, don't forget to remove the variable. With all the tears and layers I have enough overhead performance penalties. I don't need extra penalties.

Frankly, I see nothing bug ugly.

Too dense for me.

What's with the unused "snapshots" variable? You could write

_ => ...

Should look even more dense ;)

And why is the type of "agg" so similar to the QueryAgg..Snapshot type?

Anyway, I like it.

Do you really need to turn the result into an array ( .ToArray() ) at the end?

@Omer - Yes, in order to force evaluation and convert the results into a form that can be safely cached and reused.

Very nice code! I noticed that ever since I started using ruby, my code is starting to look more and more succinct like this in C#. Couldn't the projection be made simpler without the assignments?

I like it. To me it's not about density or beauty, it's about readability. Your example has that (largely due to your formatting and whitespace). Nice.

I think it's just right

Couldn't caching be achieved without the GetReportSnapshot method itself care about the cashing?

Pity the poor person who has maintain it years from now.

Dense code is bad for testing, bad for understanding and bad for maintenance.

For me this is the opposite of elegance.

You're probably going through a fair amount of work to make cached.Read() work without any passed in information. I would see you more as the type of person who would use aspect oriented programming to do:

[Cached]

public IEnumerable <iqueryaggregationshapshot GetReportSnampshot()

and have it do the

cached.Read followed by the wonderfully compact write.

This looks like memoization. Here's my variation on this:

private Memoizer <ireportsnapshot reportSnapshotMemoizer = new Memoizer <ireportsnapshot();

public IReportSnapshot GetReportSnapshot()

{

reportSnapshotMemoizer.Memoize(() =>

{

    // obtain snapshot

    return reportSnapshot;

});

}

Another variation I use in Gallio is a KeyedMemoizer <tkey,> which is basically a simple dictionary-based lazily populated cache.

Doh! I missed a "return" statement in there.

return reportSnapshotMemoizer.Memoize(() => ....);