Rethinking “Nearly VB”

Bill McCarthy added a comment to my blog which I wanted to answer:


 


So why not use VB for the templates but C# for the initial output rather than some “Nearly VB” . Doesn’t C# address every issue you’ve raised ?

But I am curious as to what about issues that are language specific, such as declarative event wiring, optional parameters etc ?



C# fixes the majority of the issues I raised, except ambiguity in closing brackets. If you assume that the closing of a structure will always be at the same level and outside embedded expressions such that you maintain symmetry in relation to the evaluation stack, you can resolve the closing brackets. Retaining symmetry in closing brackets means that the following will work:

  

   Return _

   <code>

      if (x == 1)

      {

         <%= MoreStuffFunction() %>

      }

   </code>.Value

Any variation of the following will not work:

   Return _

   <code>

      if (x == 1)

      {

         <%= MoreStuffFunction() %>

         <%= “}” %>

   </code>.Value

Which means among other things you cannot do:

   Return _

   <code>

      if (x == 1)

      { 

          <%= StuffFunction() %>

         <%= If(z, “}”, MoreStuffFunction() & “}”) %>

    </code>.Value

But you can rearrange it to:

   Return _

   <code>

      if (x == 1)

      {

      <%= StuffFunction() %>

      <%= If(z, String.Empty, MoreStuffFunction()) %>

      }

   </code>.Value

Bill believes this symmetry restriction is less onerous than the restrictions I placed on VB, especially the open/close parentheses on method calls. Another significant value to the C# first approach is that it’s much easier to recognize equals comparisons in assignment statements, and some of the null comparison problems I’m currently ignoring will be lessened because C# does not allow certain comparisons with nullable that VB allows.

While Bill convinced me that the C# first template was not nearly as difficult as I imagined it, by convincing me the restriction on the location of the close brackets in symmetry with the open was reasonable. However, he didn’t convince me to change my current work. VB first is the best scenario for my current client and I think if we have the possibility we should try to supply both so people can write and maintain their templates with the output code that they prefer, and prefer to debug the first version of the output in. Hopefully this can happen, but the most important thing to me at the moment is getting a working version out to you to play with – I don’t want to derail that with a second template converter/preprocessor. If someone else wants to work on that…J let me know.

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>