Mater artium necessitas

Archive for June, 2006

Reflection is a hugely useful technology: it allows you to get inside objects and get their intimate details, modify their values and even rewrite part of their code.
Today I wanted to build a simple treeview control that would display the hierarchical structure of an arbitrary object by going through its properties and building a tree-like structure. Useful to visualise the internals of an object and see changes at runtime.

Using PropertyInfo you get enough information about a particular property to decide if you want to display it or recurse into it if it’s a complex type that contain other properties.

But what if you don’t know anything about the values contained by the indexer?
Well, unless you use attributes to decorate the indexer or the underlying storage field with specific custom information, you’re basically screwed.

To understand why, just consider how the indexer is implemented:
When you pass it a DateTime or a string as a parameter, it just passes it on to the getter/setter as the value.
What is done with that is up to the implementer.
If you want to maintain a collection of some kind, then you need to use private fields to hold the keys and their values.
.Net doesn’t store the values passed to the indexer or the values returned by it anywhere.

Consider how .Net doesn’t give you any means of iterating through the keys and values of an indexer.
You can’t do a for(;;) or a foreach() loop, you can’t even know how many items are maintained through the indexer by directly questioning it.
So, it certainly is normal that you cannot get anything out of the indexer without knowing exactly how to access it.

The Observer Effect

In many fields of science, the act of measuring something, whether it’s an electronic circuit or a psychological experiment, can actually influence the observed phenomenon.
This is unsurprisingly called the Observer Effect.

In .Net, Reflecting on object can be very much the same.

Consider the use of Reflection when it comes to getting information about an object:
You use metadata describing the object to get more meta data information about its members
You can use that meta data to direcly query the state of an object.

If you limit yourself to getting metada, then no harm is done: you’re not querying the object instance itself but the metadata about its class.

If you start querying an actual object instance for its values then you are actively interacting with it.
In most cases, if you’re just getting the value of Fields or Properties defined as follow, then it’s fine:

Now what we’ve got here is a case of lazy loading or lazy initialization.
The consequence is that by querying the Collection property we’re actually creating it, with a potential for a lot of side-effects, like the change of other properties, here maybe related to opening the database connection for instance.

So, when getting values of the properties of an object instance, we can actually completely change its state.
Whether this is a concern or not really depends on what you’re trying to achieve: you may not be able to achieve being a passive observer using Reflection unless you know about the construction of the particular class you’re dealing with.
Using Attributes, you could give hints about which Property not to query and which Field to get instead. In our case, we could add a custom attribute like [ImplementedBy("_collection")] to our Collection property for instance.

If you want to do something generic, then you’re out of luck it and have to deal with that fact.
One possible way to minimize the effect would be to not query Properties that only have a getter and no setter, but that’s not a guarantee that all properties that implement a getter/setter are going to play nice.
Then there is also the -probably rarer- case of the Property that only has a setter.
Then there is also the case of the property getter that has some in-build security and will return different things depending on who’s calling…

All this seems pretty obvious once you understand the whole picture but it’s easy to get so impressed and dazzled by the power of Reflection that you don’t realise its natural limits.

WordPress is pretty good, but it comes with no code formatting tool, yet colouring facilities.
I like the simplicity of dp.SyntaxHighlighter for displaying source code in web pages: it works with major browsers and degrades fairly well.

Its particularity is that is does its painting magic on the client side. This can be a drawback in some instances, where the client browser has JavaScript disabled for instance, but since the code to paint is located within tags, it will still display no matter what.

Configuring _dp.SyntaxHighlighter_to work in WordPress is pretty easy: just add the relevant code in your WordPress templates for header and footer according to the instructions found on the website and you’re done.

The issue though is making it possible to insert code when writing a post.
First of all, I doubt that there is any elegant way to make one of the rich HTML editors work well, so you’ll have to go back to basics and edit in HTML (WordPress at least hides the <br> and <p> tags so its’ not too bad).
Then there is the issue of WP adding the <br> and <p> to replace linefeeds, and this is where it becomes annoying: if you insert tags, everything in it will have the extraneous formatting code that will display verbatim on screen, sprinkling your nice source code with ugly html tags.

I then modified it a bit to take care of the tag and the fact that we needed to take the attributes of the tag into account (dp.SyntaxHighlighter uses the class attribute to configure options for how to display the block of code).

SQL

XPO is an Object Relational Mapping .Net product from Developer Express, a cool company designing cool tools.
It’s a programming component whose job is to abstract access to database while allowing the developer to concentrate on a simple object-oriented interface instead.

There is an impedance mismatch between the usual programming technology and the database worlds.
The mismatch occurs because most development is object-oriented and most database systems are query-based.
Getting data from the database into your objects and back is tricky and difficult to maintain: any modification in either camp needs to be reflected to the other.

One solution is to use an intermediate layer to take care of the impedance mismatch for us: that’s the job of he ORM.

When I initially took the decision to use an ORM I tried and reviewed a few. Each have a different way of doing their job and place emphasis on different things, depending on the school of thought they belong to.
Most still require a database-centric view and either abstract the whole and let you deal with meta-data that used to modify both code and database or they just let you modify the database and then update automatically the code.
Then there was XPO.
This one was a bit different: it really completely abstracted the database. It would create and update it automatically (whenever possible) without you having to ever deal with how the data is stored: it would work in the exact same way regardless of the underlying chosen database.
You could even use it on an already existing database and it would be happy to talk to it.

So I chose XPO.
It didn’t have fancy designers but it offers a simple, reliable and flexible way to persist my objects in the database of my choosing.
One thing to note too is that you can get it with full source code (not commented though).
I find it reassuring when a company doesn’t mind its code to be scrutinised by its customers. It’s also proven invaluable in finding out XPO’s inner working (not that I understand a lot though).

I’ll be blogging a few articles in the future on various aspects of XPO that I think may be of interest to those already working with it. I’m not going to re-state what’s in the documentation or on the Developer Express (DX) community website and official pages, there is a lot of information available out there, it’s just sometimes hard to get to know the fundamentals because it’s sometime buried deep.
Whenever possible (depending on time and complexity) I’ll make a sample project. I’m even thinking about building a repository of samples showcasing various aspects of XPO.

Let’s see if I can hold the load for long…. I’ve also committed myself to DXCore recently… but that’s something for another post altogether…

I was visiting http://www.paraesthesia.com/ for the latest version of a VS Studio add-in and Travis, the owner of the site, had his “Star Trek profile”. I suppose most people working in technical fields turn out to be the same…

In a past life, working as a project manager for a manufacturer of railway equipment, I had to deal with detailed specifications and conditions of contract that would be big thick documents of hundred of pages each.

Refactoring code is a necessary thing. Unless you work in some very specific environment where casual refactoring is not allowed (like in some safety-critical applications where the most minute change has to be pondered upon by teams and committees for weeks), you cannot code perfectly on the first shot.
More often, you end-up reviewing code and making it clearer, merging parts that are too similar, removing what turned out not to be useful, cleaning up the names, moving things around, etc… there are dozen of refactoring cases that usually help remove the stink out of it.