Suggestion for an addition to the Code Document Object Model

As far as innovation goes, I find the current CodeDOM to be a great leap forward in the field of tool-making. I think that its structure is sound and is a great start. However, several little bugs can cause a person to go mad (such as the lack of support for InitOnly, as I have noted before), and should be quickly fixed.

The one thing that is most upsetting to me is that while IL may be compiled from many different languages, with many different features (C# and VB.NET both have the foreach construct, C# has the using construct, etc.), CodeDOM only utilizes the very lowest common denominator.
This pains me as a developer when I want to write a generator that is language-specific or one that requires a certain construct.

My suggestion would be a superset of classes that will be language specific with inter-language translation mechanisms.

For instance, let’s take a CSharpUsingStatement class (which derives from CSharpStatement which derives from CodeStatement).
Now I want to create my code. What I do is run the code through the CSharpCodeGenerator and voila! I have the a ‘using’ statement in my generated code.

But, you say, what if I want to generate my code in VB.NET’s syntax?
Then – an inquiry will be made to the central factory, CodeDomTranslationServicesFactory (that will have an extendable set of classes to manufacture, in case I implement my own specialized CodeDOM) which in turn will supply me with a CodeDomTranslationService object that could translate the object of type CSharpUsingStatement from its original form to VB.NET’s CodeDOM.
But alas, this is not a construct familiar to VB.NET and so a call will be made to the factory for a C# CodeDOM to Common CodeDOM translation service. This service will then translate the statement to a try/finally code block.

On the other hand, a CSharpForEachStatement object could easily be replaced with a VisualBasicForEachStatement object using the correct CodeDomTranslationService.

Such methodology would allow us all to enjoy both the generic-ness of CodeDOM and the powerful abilities of language specific constructs.

I would love to hear your thoughts on this.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s