Ayende @ Rahien

Jeff Brown commented on Dense code

Mon, 11 May 2009 20:24:34 GMT

Doh! I missed a "return" statement in there. return reportSnapshotMemoizer.Memoize(() => ....);

Jeff Brown commented on Dense code

Mon, 11 May 2009 20:23:33 GMT

This looks like memoization. Here's my variation on this: private Memoizer { // obtain snapshot return reportSnapshot; }); } Another variation I use in Gallio is a KeyedMemoizer which is basically a simple dictionary-based lazily populated cache. >

Kelly Stuard commented on Dense code

Mon, 11 May 2009 14:33:14 GMT

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

Ian Chamberlain commented on Dense code

Mon, 11 May 2009 09:38:45 GMT

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.

Martin commented on Dense code

Mon, 11 May 2009 08:31:13 GMT

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

PandaWood commented on Dense code

Sun, 10 May 2009 07:04:29 GMT

I think it's just right

Jacob commented on Dense code

Sat, 09 May 2009 20:33:14 GMT

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.

nightshade427 commented on Dense code

Sat, 09 May 2009 18:07:22 GMT

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?

Ayende Rahien commented on Dense code

Sat, 09 May 2009 17:26:35 GMT

Omer, If I wouldn't do that, I would cache the query itself, not the query results

Ayende Rahien commented on Dense code

Sat, 09 May 2009 17:25:59 GMT

Frank, The unused value is the previous value for the item, which allow you to make modifications. It is not used here. The reason for this is that I want to create an immutable snapshot

Jeremy Gray commented on Dense code

Sat, 09 May 2009 16:40:26 GMT

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

Omer Mor commented on Dense code

Sat, 09 May 2009 16:20:18 GMT

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

Frank Quednau commented on Dense code

Sat, 09 May 2009 15:46:16 GMT

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.

Colin Jack commented on Dense code

Sat, 09 May 2009 15:01:15 GMT

Too dense for me.

noone commented on Dense code

Sat, 09 May 2009 13:14:23 GMT

Frankly, I see nothing bug ugly.

Dave commented on Dense code

Sat, 09 May 2009 11:04:43 GMT

@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.

Thomas Eyde commented on Dense code

Sat, 09 May 2009 10:43:22 GMT

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

Chris Martin commented on Dense code

Sat, 09 May 2009 10:08:00 GMT

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

Sasha Goldshtein commented on Dense code

Sat, 09 May 2009 09:44:19 GMT

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.

JeroenH commented on Dense code

Sat, 09 May 2009 09:41:51 GMT

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

Michael Morton commented on Dense code

Sat, 09 May 2009 08:47:19 GMT

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.