Omer van Kloeten's .NET Zen

"What has been will be again, what has been done will be done again; There is nothing new under the sun."

I started writing a little framework that takes an object grid and visualizes it using forms created on-the-fly.

What I have right now is that if you run the following code (note the Main method):

namespace DotNetZen.ObjectExperience.Tester
{
    [Style(typeof(DefaultStyle))]
    public class TestClass
    {
        private string m_SomeText = string.Empty;

        [Field]
        public string SomeText
        {
            get
            {
                return m_SomeText;
            }
            set
            {
                m_SomeText = value;
            }
        }

        [Field]
        [LiteralDescription("Some ReadOnly Field:")]
        public string SomeOtherText
        {
            get
            {
                return "w00t!";
            }
        }

        public string SomeOtherNonFieldText
        {
            get
            {
                return "w00t!";
            }
        }

        [STAThread]
        static void Main() 
        {
            TestClass tc = new TestClass();

            Application.Run(DotNetZen.ObjectExperience.ObjectViewer.Experience(tc));
        }
    }
}

I showed it to Avner, who gave me the quote in the title and showed me the Naked Objects site. It's quite impressive and is exactly what I thought of (sans the whole part about persisting the data; I was planning on the use of a good O/R mapper for that).

Still, I'm gonna go on playing with this, as I add new style choices, use less reflection, add i18n, etc.
I wonder what could come out of this. :)

CodeReviewWiki

Mitch Denny has set up a wiki to collect useful tips for code reviews.
I already went and added some of my past advice there. You should too, since it seems like a great resource for reviewers.

gg, mitch! :)

How Microsoft Built A Feature I Will Never Use

I just got a response on my suggestion on ladybug regarding keyword autocompletion on Visual Studio 2005:

At this point in time, intellisense allows you to get a list of available keywords and code snippets as you type. This is a very nice functionality (even though I have disabled it for the time being), but it can be improved, as these 'suggestions' are likely to break your code, syntax-wise. Take, for instance, the case where you write a public instance method that returns an instance of a type which starts with the letters "pub". Hitting Ctrl+Space after writing 'pub' for the first time completes to 'public', but the second one would do so as well, even though the keyword 'public' is illegal in that context. This is one of the only things that keeps me from enabling this option.

Jay replied:

... I hope that in the next version we'll get a lot smarter about keywords we show, which I will be a nice thing for all users, and a huge win for novice C# users.

This is a total waste of feature:
Imagine intellisense in the XML editor in Visual Studio. When faced with a known schema for the current file, it will let you choose the appropriate element for the context it is inserted into (if A can only be nested under B, it will only show A in the completion list when inside a B element).
Imagine the XML editor devoid of that ability - showing you every single declared element in the schema. Would you use that?

.NET On The Beach

I was at the .NET On The Beach conference yesterday. Won a mouse for answering a question (first time I won anything at a conference - yay me :D).

Yosi lectured about some new features in Visual Studio 2005, but I was disappointed that none of them got me excited too much... (and this was about things I didn't really hear much about like templates for ASP.NET pages and ClickOnce)
The coffee machine trick was pretty neat (a robotic arm was programmed to "Make coffee according to a task written in MSBuild given how much water and coffee was passed as parameters"). Kudos to the guys who made it work!

I really enjoyed it, and didn't let the 2 hour drive there (on a usually 30 minute drive) spoil the fun.

Oh, and Microsoft Israel, next time you decide to bring belly-dancers, try and get people in the mood first. (Yosi in a fez just doesn't cut it ;)

p.s. nice question over on Avner's blog.

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.