Skip to content


Exposing child objects

Consider a business object that has a list of child objects. Let's assume that the parent has to do some housekeeping operations when children are added or removed, and also has some rules what children are legal to add.

Before delving into various solutions using collections, let's consider the problem of ownership of the data returned from an object.

While the access scenario of

foreach( FooChild child in Foo.Children)

is the desirable one, there is no stopping someone from doing

FooChildren[] children = Foo.Children;

and then carrying the collection around. Of course, the moment the collection changes inside Foo, the child collection retrieved is invalid, since it was an array and not re-sizable. Would that violate your expectations? I generally consider Properties to be Accessors, i.e. you get the value used by the object, not some clone for you to manipulate without affecting the originating data. And the above scenario would violate that expectation.

So are Properties really an object's data and results retrieved from a method such as GetChildren data for you to manipulate without an expectation of changing the data in the originating object? If not, can the rules governing retrieved data be expressed in code, or is this type of contract something that is only going to be communicated through documentation?

If we proceed that the expectation is that once you get a collection back from a property it's still associated with the parent we get behavior similar to Xml Nodes. That solution would look something like this:

foo.Children.Add(new FooChild());

Pre-C# 2.0, you'd have to create your own strong-typed collection object for the children. If you do this more than a couple times, that's a lot of repeated code, what with all IEnumerable requirements. But it does provide you the added benefit that you could define events for the parent to be notified when things happened, so it could execute its constraint logic, which an untyped arraylist would not.

In 2.0, the whole thing could be done with an ICollection or, even better, an IList. But you'd still have to write that generic class yourself because (AFAIK) there are no implementations that have events to notify you when the collection changes. All things considered, though, this promotes much better re-use and a cleaner interface.

Or is there a better pattern to follow that i've not touched on?

VS.NET 2k5 final and Nullable types

Got the official release installed and had to make a couple of changes to my nullable code that was written against Beta 2. All good, though. It was just taking out hacky crap that branched on INullableType in generics code. Glad to see that nullable types are null when boxed now. Way to go CLR team!

However, the ADO.NET stuff isn't quite there yet. But at this point it's not so much a nullable type thing instead a matter that DBNull just isn't null, so you can't just cast a return value to a .NET type. Still makes writing typed DB interfaces a bit annoying. But with generics, it's at least worlds better than it was before.

Joe Jobbed

Looks like got Joe jobbed. For the past two weeks or so some bastard spammer has been using as their return-address domain. And so i've been getting a lot of bounce mails from all over the world. Fun.

First thing, of course, i made sure I wasn't compromised and my hosts was actually being used for the spam. From examining the headers of the messages bounced to me, it looks like the originating hosts are a bunch of zombies, so there isn't even any use in contacting the owners of the hosts that sent the spam.

For now, i'm just going to sit tight and filter incoming messages. Hopefully, the next rev of the zombie moves on to some other unlucky domain owner. And equally hopefully, i won't be on some blacklist because someone didn't check the origination of the spam. Ho hum.

Nullable Types and ADO.NET don't like each other

Hopefully this will quickly be proven to be out of date, but at least as of the June CTP of C# 2.0, nullable types are not welcome by SqlParameter objects. This strikes me as extremely odd. Personally, I thought the whole reason to add nullable types to C# 2.0 is to finally get rid of the Value Type/Database Type disconnect over null values.

The biggest frustration building type-safe database interfaces has always been that value types cannot be null, but any column in a database can be null. I should stop here and also point out that 99% of the time columns in database are marked as "allow null" when they shouldn't. A column should only allow null if that null has a special meaning. Half the time people just use null to mean 0 for ints and then you get a lovely mix of 0 and null in there that means the same to business logic, but you have to treat watch out for when you run your reports against that table. Don't use null, unless you mean it! But I digress...

Type-safe database interfaces want to pull datatypes from the DB as their native types. So an int in the DB shoud be an int in code. But what do you do when that int allows null, to mark an unset value for example? Do you create a magic number like 0 that means null? Do you store it as object internally after all and throw exceptions when someone tries to access the null value? None of the solutions are all that appetizing.

Then C# 2.0 introduced nullable types. Value types that could have a null value. Yay, the disconnect has been plugged! Or so I should until i tried executing my first SqlCommand that had an SqlParameter with a nullable int passed in. It promptly threw an invalid cast exception.

So for the time being, at least, I get to do a fun little dance of checking for is INullableValue and then casting the value to INullableValue so I can check HasValue and use Value to get the underlying type. We'll see what happens with the release version of Visual Studio 2005 in December.

Emacs Keybindings in VS.NET 2k5

Just discovered that VS.NET 2k5 has a preset under Keyboard mapping scheme's for Emacs... Yay! It only remaps things that exist to Emacs commands, i.e. you don't get a killring on Ctrl-Y, but it's something.

VS.NET 2003 to 2005

I recently started playing with VS.NET 2005 Beta 2, mostly because I wanted to see the Class Designer in action. The first, pleasant surprise was that it co-exists peacefully with VS.NET 2003. I was afraid i might hose my daily dev environment with this experiment, but it seems to be ok. Haven't tried ASP.NET yet, since the switch, but i hear that IIS is the one bone of contention with peaceful co-existence.

But enough about the pleasantries. Converting some work projects, i came across a C# language change that I'm not sure is a change or a fix for a bug. Either way it makes me change my code...

namespace ConsoleTester
    public class Base
        protected Base()

        protected Base(string x)

    public class Child : Base
        private Child()

        public Base MakeBase()
            return new Base("foo");

This works in C# 1.0, but in C# 2.0 i get Cannot access protected member 'ConsoleTester.Base.Base()' via a qualifier of type 'ConsoleTester.Base'; the qualifier must be of type 'ConsoleTester.Child' (or derived from it). So is this a change in the spec, a bug in 1.0 or a bug in 2.0?

The new math.. er--trig

A friend of mine just pointed out DIVINE PROPORTIONS: Rational Trigonometry to Universal Geometry. Having had to refresh my Trig understanding for a number of recent projects (basically any time graphics are involved), I like the concept of getting rid of sin, cos, etc. in favor of simpler rational math.

But what's even more interesting about Divine Proportions are its implications for graphics processing. Being able to get rid Trig functions in 3D calculations and replace them with simple squares and fractions should allow some significant speed increases in processing. Curious how this plays out.

String Formatting in C

I google this every time, i need to put a float inside of a String.Format() call. Never found a good reference, so i made a note to the place i got the answer from.

Those days are over! Steve Tibett has an excellent article on the subject

Update: Updated the link, as Steve Tibbet's blog software changed and with it the url.

Detecting ASP.NET

I've been wondering for a while how you could reliably tell if you are currently running under ASP.NET. This is really only of interest to be because of the ThreadSingleton vs. Static Singleton issue. The best way I've found so far is:

bool isASP_NET = ( System.Web.HttpContext.Current == null )?false:true;

Kind of annoying, because you have to reference System.Web in your Project, which you wouldn't otherwise.

I looked through most of classes that come out of the System and mscorlib assemblies but couldn't find anything good and reliable (i.e. didn't want to use AppDomain and see if the config file was called web.config.. Sounds like an accident just waiting to happen.) Still, there's got to be a better way.