Syntactic Sugar

I just got a .NET Briefing e-mail newsletter in which the author purports to (among other things) take on the OOP-ness of the ASP.NET control architecture. In it, he compares the following two pieces of code (bold mine):

<asp:Repeater ID="myRepeater" runat="server">
<ItemTemplate><p><strong>Name: </strong>
<%# DataBinder.Eval(Container.DataItem, "UserName") %></p></ItemTemplate>
</asp:Repeater>

<asp:Repeater ID="myPythonRepeater" runat="server">
<ItemTemplate><p><strong>Name: </strong>
<%# UserName %></p></ItemTemplate>
</asp:Repeater>

The first is the traditional C# way of doing a Repeater, while the second is the IronPython equivalent. The author writes:

That’s quite a bit cleaner and easier, right? As Scott Hanselman likes to put it, that’s just the effect of “syntactical sugar” thrown into the mix to enable developers to type less. Under the covers, data-binding is still going on and you’ll obviously need to wire up a data source . But this is a much easier way to handle data-binding, even if it doesn’t look pure from an OOP standpoint.

Is this really that big of a deal? Sure it’s cleaner, but what does this have to do with theoretical arguments about data decoupling and the new ASP.NET MVC architecture? Not much. Syntactic sugar is a tricky subject to deal with, but regardless, it rests above (in the stack-dependency sense) the deeper issues of decoupling and architecture.

Advertisements

0 Responses to “Syntactic Sugar”



  1. Leave a Comment

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s





%d bloggers like this: