Mapping

Will code for food!

A lot of code written today just moves data from one place to another and/or maps data from one structure to another. Right now I’m consulting on a project where the code I write is:

converting an socket stream to an xml document
converts the xml document to c# objects
converts the c# objects to linq objects (created by a database scheme)
uses the linq objects to update the database and something for going the other way as well.

The database scheme was written by me by hand based on the xml document.

This particular process could/should be totally automated since there is a 1-1 mapping from one way to the other. There are so many errors that can be made during the writing of this code (note: linq brings me some of the way - but not all, and I notice this pattern in modern programming WSDL's, POM's etc. etc.).

The real core of Dawn (the mindset behind it) is mapping. The mapping is coming from the library and the flowing of data. Conventions of mapping should be created and used when no special requirements are present. However we are forced to hand code the mapping over and over, hereafter debug it over and over.

I’m tired.

Reverse the power

The previous post was about what I hate, but it’s not very constructive to talk in negatives, and the obvious question would be "Well, what do you want to put instead then?".

I was pleased when I saw the override keyword in C#, because that illustrates the reversal of power. The user specifies that he intends to override a function, so the compiler can warn him of misspellings etc. Still the virtual keyword has to be present at the other side, so it’s not entirely rosy for my glasses.

Template/Generics is another place where power resides with the designer. The designer decides that you need to be able to utilize this code, for different types, but he decides entirely what can be changed.

Dawn allows the user to alter the lookup of names (read:types although dawn is prototyped). This allows the user to alter every type inside the black box of the API. Of course this is incredibly powerful and thus dangerous, but Dawn allows the change to be totally local, and the user should know that this is potentially dangerous. This is another point - I don’t mind languages have dirty/dangerous features, but you should be aware when you use them.

To sum up, reuse have failed insofar because power has been with the designer, not the user. Reversing this might lead to greater reuse.