Greg Beech's Tech Blog - All Comments

re: Disposing and finalizing partially constructed objects

Dale — Wed, 27 Aug 2008 23:08:56 GMT

You can call dispose from the constructor's catch block for a convenient way to clean up a partially constructed object. Just make sure that the dispose method makes no assumptions about the state of the object. ie. Check each field for null before trying to do cleanup on it, for example.

re: Why doesn't System.Linq.Enumerable have a ForEach extension method?

wekempf — Tue, 26 Aug 2008 14:25:54 GMT

I guess I'm looking at this from the perspective of functional programming. The ForEach concept isn't chainable. In functional languages we're generally interested in only two chainable operations, Map and Filter, both of which exist in LINQ in the forms of Select and Where. Then we're interested in Reduce, which maps to Aggregate in LINQ. All other operations (include ForEach/Each/Loop) can be implemented on those operations alone. For instance, to print out the values you could do this:

list.Select(x => { Console.WriteLine(x); return x; });

However, since we're not altering the list, it's preferable to use a function that codifies this, so we have various loop/for/while functions. Since these loops don't modify the list, they don't return anything, and thus are not chainable. ForEach in LINQ should return void, and by necessity should not be deferred. No developer that's worked with a functional language will find this surprising... though they might take issue with the names chosen for LINQ. ;)

I certainly agree with your assessment that the ForEach loop concept isn't chainable, and should be immediately executed and return void. This is how List.iter works in F#, how each works in Ruby, and indeed is what I implemented in our core library. I'd be happy enough if this is what was implemented in the base class library (or the one that takes a param array as in one of the above comments).

But it's also a valid concept in an impure language to want to add some lazy processing for each item in a pipeline (e.g. to log the item details) and in this case the ForEach method name would also seem appropriate. All I was trying to get at is that ForEach could mean different things to different people, and it isn't immediately obvious from the method name what that meaning should be.

Maybe the best solution of all is to call the immediately executed non chainable version something like Iterate instead of ForEach, which makes it absolutely obvious what it does.

re: Why doesn't System.Linq.Enumerable have a ForEach extension method?

wekempf — Mon, 25 Aug 2008 20:07:11 GMT

I commented on Glenn Block's site, but I'll say it here as well. Not all LINQ operations are chainable or deferred. Average and Sum are neither. I would not expect to be able to chain ForEach, nor would I expect it to be deferred. I doubt any of this is the reason ForEach is missing in action.

Not all LINQ operations are chainable or deferred, however (as I actually said in the post) all operations that are chainable are also deferred. It might appear that this does not hold true for operations which explicitly convert the sequence to another enumerable type (e.g. ToArray, ToList), though here you aren't really chaining to the original query, you're beginning a new chain from a new object, so it actually does still hold.

Arguably, then, if you make ForEach chainable you should also make it deferred, and if it is not chainable then it should execute immediately (as you can see from the end of the post, the latter is the choice we went with for our core library). The problem is that this is less useful than the one that executes immediately but that can be chained. As I said, none of the methods are ideal, and you might want different semantics in different situations.

I'd be interested to know what you think the reasons are for ForEach being omitted? It certainly isn't laziness, or that they simply forgot to implement it, because this type of method is ubiquitous in functional libraries (including F#, Ruby, etc.) which means that they did leave it out on purpose.

Emitting primitive type conversions with Reflection.Emit

Greg Beech's Tech Blog — Wed, 20 Aug 2008 21:34:45 GMT

Conversion between primitive types is trivial in high-level languages like C# as you can use the cast

re: Code without comments is code that doesn't work

Neil Mosafi — Tue, 05 Aug 2008 10:29:32 GMT

Hey mate, just stumbled across your blog... it's made a good read - nice one!

It's funny, I used to really want to comment all my code. Now I am working in a place and there are hardly any comments anywhere, and it's really annoying! I have kind of got used to it now, but I do at least like to see comments explaining why a certain statement is there in the first place, especially when that piece of code was added to satisfy an edge case. e.g. I have seen code where a class receives an object, does some stuff with it, and then returns it. However deep down in the code you actually find out that the object has been persisted to the database AND THEN LOADED AGAIN before being returned. I could find no explanation for why it was loaded again after being saved, but I was too scared to remove as I thought it must have been done for a reason.

Anyway, regarding the specific issue metioned, to be honest I would probably tackle this architecturally rather than using comments. By using an interface, e.g. ISquareRootCalculator I can then inject an implementation (which used Newton-Raphson) using IOC. This way, if I did want to change the algorithm I would only be adding code rather than changing code, and I wouldn't have to update the comments aswell as the code. I don't think my class should really be concerned with the reasons a certain algorithm is chosen over another.

re: My new laptop: ASUS Lamborghini VX2s

Greg Beech — Mon, 04 Aug 2008 21:37:59 GMT

Hi Joe

Yeah, I'm still finding it to be a great piece of kit, and it does everything I need from it on a daily basis. One slight niggle I have now is that since I installed SP1 on Vista I can't get the bluetooth mouse that came with the laptop to pair with it - but that seems to be more the fault of Vista than the hardware itself. The other thing is that it really chews through batteries; in high performance mode it will drain the battery flat in under an hour, and even in normal mode it's less than 90 minutes, so if you're planning to work on the move then this might be an issue.

One thing to watch out for with the SE version you mention is that (in the UK at least) the hard disk has gone up to 250GB but the spindle speed has gone down to 5400rpm which could impact the performance quite a bit compared to the 7200rpm drive in some other versions such as the one I have (it seems the specs change for the VX2s just about every month so it might be worth waiting until there's a 7200rpm one).

The blu-ray drive and HDMI output are great for movies, and it's more than capable of running photo/video editing software.

- Greg

re: My new laptop: ASUS Lamborghini VX2s

Joe Drapela — Mon, 04 Aug 2008 21:12:29 GMT

Greg,

Am ready to buy the Asus lamborghini VX2Se-Ak001G for its abilities and of course its snob appeal.

Am curious as to your opinion since you are by now out of the honeymoon phase.

Are you still overall happy with this guy and is it worth the extra expense for the lambo logo?

My needs are for running Qbooks, and an auto business software.

My new hobby is fun editing photos and creating High Def. Blu-Ray videos.

Your opinion is greatly appreciated

re: Tips & Tricks: Use DebuggerDisplayAttribute for easier debugging

Greg Beech — Tue, 29 Jul 2008 19:01:46 GMT

Hey Sean

The reason I don't like ToString for this type of thing is because it means you should also be overriding Equals and GetHashCode as stated in the framework design guidelines. This causes problems with most objects because if you override GetHashCode then your object should be immutable, which most aren't (see gregbeech.com/.../implementing-object-equality-in-net.aspx).

Of course like all rules this one is made to be broken, for example with classes like StringBuilder whose sole purpose is to build a string it makes sense to override ToString without overriding the others.

Using DebuggerDisplayAttribute for debugging is much cleaner, and if you do need a string representation of the object then it is fairly easy to construct the output string yourself with a bit of reflection as long as you keep to the convention of just using property names rather than complex expressions (this is what we do in our tracing framework, in fact).

- Greg

re: Tips & Tricks: Use DebuggerDisplayAttribute for easier debugging

Sean Kearon — Tue, 29 Jul 2008 16:47:56 GMT

Sweet, very simple, very useful! I'd always used overridden ToString() to acheive this, ignoring the part of me that questioned whether ToString() was not far more important than to be dedicated to the debugger!

Thanks!

Database Management » Blog Archive » Dynamic sorting and paging in SQL Server with the CASE expression

Mon, 21 Jul 2008 22:17:14 GMT

Pingback from Database Management » Blog Archive » Dynamic sorting and paging in SQL Server with the CASE expression

Dynamic sorting and paging in SQL Server with the CASE expression

DotNetKicks.com — Mon, 21 Jul 2008 22:12:26 GMT

You've been kicked (a good thing) - Trackback from DotNetKicks.com

Emitting arbitrary constants with Reflection.Emit

Greg Beech's Tech Blog — Sun, 20 Jul 2008 22:52:07 GMT

I've been writing a fair bit of Reflection.Emit code recently, and along the way have developed quite

re: Object-Relational Mapping frameworks won't improve your timescales

Sean Kearon — Sun, 20 Jul 2008 16:49:15 GMT

An interesting point, Greg, and one that should be carefully considered before adopting an ORM. However, I'd agree with Dave Brasington above - using an ORM to reduce project timescales is missing the point. The primary benefits for me are flexibility and accuracy.

Data access is handled by a seperately versioned library - the ORM. My app's data access is as stable as my ORM is, minus the relatively thin layer I add to configure the ORM. The cost of change is drastically reduced from my perspective as a developer as I don't have to deal with any schema design or data access code maintenance = less dull boilerplate work.

However, I have used an ORM approach since 2002 (and have forgotten more SQL than I can remember now as a result), so I guess I'm a bit biased. Maybe I should see if I can still write SQL again sometime ;)

re: Making SiteMapPath work with QueryStrings

Dilip Nikam — Fri, 18 Jul 2008 05:15:10 GMT

We can do this way also. In this example I am showing how to add functionality of show-hide SubMenu, Enable-Disable User Click and AddQueryString.

</siteMapNode>

protected void TopNavigationMenu_OnMenuItemDataBound(object sender, MenuEventArgs e)

{

SiteMapNode node = e.Item.DataItem as SiteMapNode;

// check for the visible attribute and if false

// remove the node from the parent

// this allows nodes to appear in the SiteMapPath but not show on the menu

if (!string.IsNullOrEmpty(node["Visible"]))

{

bool isVisible;

if (bool.TryParse(node["Visible"], out isVisible))

{

if (!isVisible)

{

e.Item.Parent.ChildItems.Remove(e.Item);

}

//Block User Click.

if (!string.IsNullOrEmpty(node["IsClickAble"]))

{

e.Item.Selectable = false;

}

//Adding QueryString value In RunTime.

if (!string.IsNullOrEmpty(node["AddQueryString"]))

{

e.Item.NavigateUrl = e.Item.NavigateUrl + "?" + node["AddQueryString"].ToString();

string s = e.Item.NavigateUrl.ToString();

}

thanks Greg.....

Database Management » Blog Archive » Service-orientation is inevitable for performant database applications

Wed, 16 Jul 2008 22:26:54 GMT

Pingback from Database Management » Blog Archive » Service-orientation is inevitable for performant database applications