Jeffrey Palermo 3:02 pm on February 8, 2008

Use caution with anonymous types and other new C# language features

To subscribe to my feed, add the following Url: http://feeds.feedburner.com/jeffreypalermo.

I think Microsoft is making a huge mistake by leaning so heavily on anonymous types as API parameters, particularly in the ASP.NET MVC Framework. Not only does this make the APIs in the system ugly and error-prone, but it’s not intuitive, and there is no intellisense for it because the API is untyped (typed as object) in the case where an anonymous type is expected. I think we should stick with named types and named methods wherever possible. I currently don’t see a problem with lamda’s if they give an advantage over regular arguments. I’m very cautious about automatically using new, unproven language features before we fully understand how they will affect the usability and maintainability of code. Note: we have NO track record for the maintainability of these new language features, and they were developed specifically for LINQ, so using them outside of that context is suspect, in my opinion.

I do have a conservative disposition on this, but this is through learning from the past. I still remeber OpenXML is SQL Server 2000: how so many developers automatically converted stored procedure interfaces to be a single XML string rather than individual arguments. We need to fully understand the long-term strengths and weaknesses of features in order to maximize the value of usage or non-usage.

Aaron Erickson 6:08 pm on February 8, 2008

I guess I should start paying more attention – I thought anonymous types were for local scope, transient shapes of data. That is the only real place where I find something like that useful.

Having a public interface use an anonymous type seems like a really, really bad idea.
Ran Davidovitz 6:18 pm on February 8, 2008

I see the option to pass anonymous types same as passing an System.Object (or actually an open dictionary).
While using Anonymous types make the code more generic and add ease of programming it still causes, as you said, to not see the full contact of the API and eventually people will always need to read the manual to use the API.
You can see example for this in ExtJS framework (JavaScript) that the constructor get a JSON object that you simply have no way to know what to pass without re-reading the docs.
wekempf 8:09 pm on February 8, 2008

I don’t think you are informed on this topic. In C#, anonymous types can’t be used in the public interface. The work only in local scope. They are also strongly typed. The IDE understands them just fine, and displays the appropriate intellisense.

You’ll have to be a lot more specific about how you think this concept is harmful, especially with regard to the MVC framework. Where is an anonymous type used as an API parameter there?
Garry Shutler 8:26 pm on February 8, 2008

@wekemf, if you want to create default parameters or create a link to a specific controller action you have to use something like new { controller = “MyController”, action = “MyAction” }
Jeffrey Palermo 8:30 pm on February 8, 2008

@wekempf,
No problem. I can be more specific. Let’s take the Route class, which is one of the first things you define when creating an ASP.NET MVC application:

public class Route
{
. . . .

// Methods
public Route();
public Route(string url, Type routeHandler);
public Route(string url, object defaults, Type routeHandler);
. . . .

public object Defaults { get; set; }
. . .
}

In the constructor, what is this object “default”. The property “Defaults”. What is the type? This is specifically what I’m talking about. What is _expected_ is that an anonymous type with _just_ the right property spellings is passed in. This is a bad API. Clearly the class requires a specific object with specific properties, but the API lies and communicates that any object will do.
Alan Mojab 8:49 pm on February 8, 2008

I tend to agree with you on anonymous type issues. I’ve recently read about “Dynamic Lookup” another late binding language feature MS is adding to CLI 4.0.

I think in real world both Anonymous types and Dynamic Lookup have very little use in 100% managed environment. It appears to me Microsoft has been adding these features for their own use mainly.

I can only speak for myself in here that I would never design anything that would require late binding features. I might be missing a point in both but I always thought abstraction can overcome the late binding challenges in managed environment.

In design point of view when one is developing a framework there are challenges that aren’t easy to solve. Some of these challenges can be solved by using the late binding technique. Since most systems being developed aren’t a framework or if there are then they are being used by an enterprise system it is possible to avoid using late binding approach in general.

What concerns me mostly is that developers might use a feature because is just there without spending more time to understand the problem on hand better. I think we developers need more caution reminders like your post.

I always said that in Software Development the hardest thing is to keep the logic of the code simple and manageable, something most take it lightly. For sure late binding technique makes everything far more difficult but not impossible.
wekempf 8:53 pm on February 8, 2008

Great. I’m not familiar with ASP.NET MVC (other than reading the hype in the blogs). I can tell you that what you just showed is an abomination that has little to do with the anonymous type features in C#. There is no anonymous type in the public interface. However, based on your description, I must assume that in the implementation “defaults” is interrogated via reflection for certain properties. The idea is to provide “named arguments” in C#, like you have in some languages, such as Python. So, you could call it something like this:

Route r = new Route(url, new { Foo=”bar” }, typeof(SomeRouteHandler));

That’s just horrendous code. Performance would be terrible. You’d be better off using a Dictionary rather than an anonymous type, because you’re relying on reflection. You can’t decry a language feature because someone chooses to horribly abuse it like this. After all, you can’t name a single language feature in any language that couldn’t be abused by someone.

This isn’t the purpose that anonymous types were created for. It’s also simply a bad idea, IMHO.
wekempf 9:03 pm on February 8, 2008

I found an example of Route being used, here: http://forums.asp.net/p/1205871/2110762.aspx#2110762.

Again, I think this is simply misguided abuse. Defaults should be strongly typed. This is especially true if, as you suggest, reflection is being used to access the properties on the anonymous type. This indicates a closed key/value mapping, and using a strongly typed object would vastly improve the performance here.
Jeffrey Palermo 9:04 pm on February 8, 2008

@wekempf,
>You’d be better off using a Dictionary rather than an anonymous type, because you’re relying on reflection.

Exactly my point.

>You can’t decry a language feature because someone chooses to horribly abuse it like this

I would agree with that statement, and I would not decry anonymous types as a language feature even though it is being misused.
Kelly Leahy (Milliman) 10:16 pm on February 8, 2008

Unless I misunderstood something here, Jeffrey is just saying he doesn’t like the usage of anonymous types in these examples, not that he doesn’t like the fact that these types exist in the language.

If I understood him correctly, I completely agree! If you want to use anonymous types in the local scope to solve some problems that it’s nice to have those language features for (rather than having to type a bunch of ‘declaration’ code), I’d say that’s GREAT. But, I don’t think you should be passing those types somewhere else…

I think a nice feature would be if an anonymous type could automatically implement an interface, just by casting it (and having it check at compile time that it has the proper members). That way, MVC could get the same benefits that they are looking for without the mess of having to create a ‘real’ type to implement the interface…

For instance, what if some interface was declared:

interface IRouteDefaults
{
string param1 { get; set; }
string param2 { get; set; }
…
}

and you could say:

new Route(url, new { param1 = “value1” } as IRouteDefaults, typeof(SomeRouteHandler));

and have the compiler automatically do:
1) implement IRouteDefaults on the temporary type
2) provide the default implementation for param2 (which is ‘null’ in this case)
3) provide the pointer to this interface to the constructor.
Peter Ritchie 10:18 pm on February 8, 2008

They using Object for defaults and Defaults because they’re leaking anonymous types from local scope? Yuck, yuck, yuck, yuck, yuck. Oh, did I say, yuck. I recommend using anonymous types for short-lived (i.e. kept only to local scope) data. That’s potentially forcing it to be long-lived data.
sergiopereira 1:54 am on February 9, 2008

Amen. In a few months whoever came up with this great idea will be sorry – unless it’s removed from the API, there’s still time.
rjevans 2:27 am on February 9, 2008

I’m not against late binding in principle; it’s hard to be like that given that most .Net ‘data binding’ is in effect ‘late binding’.

The problem that I see with this usage is that it constitutes an ‘opaque contract’, in so far as the client has no immediate way of determining what expectations the API has.

So in the extreme worst case, this could trigger significant trial and error as a client developer struggles to work out what really needs to be supplied to satisfy the (ambiguous) contract through (mis)reading the documentation and perhaps even being forced to debug through the target API calls.

If an API does have contract expectations that go beyond what System.Object provides, then these need to be clearly communicated and should be easily verifiable prior to making API calls (ideally at compile time).

The only upside of this usage of System.Object is that it is somewhat better than the dreaded ‘Name of Object’ supplied via a String usage, e.g. string objName =”foo” to refer to the public object ‘foo’ in a call such as myClass.doSomethingWithObject(“foo”). Which I’m sure is expressly intended to bedevil those of us who are prone to misstttyyyping occasionally (thanks be for Intellisense and the compiler, but sadly they don’t work inside strings ) .
Hadi Hariri 8:31 am on February 9, 2008

+1
Lance Fisher 8:02 am on February 10, 2008

Figuring out routing in ASP.NET MVC was as easy as firing up the reflector 😛 But I don’t mind the anonymous types in some other situations, even as parameters to methods. Such as methods that create HTML where you already know the attributes well, and you usually only need/want a couple of them. It does make it more difficult to pick up the framework though.
Jeffrey Palermo 5:06 pm on February 10, 2008

@Lance,
The methods that create HTML (View helpers) do accepts html attributes, and, yes, the html attributes are well-defined, so it should be _really_ easy to create a simple object model around them. Then, the object initializers feature allows you to create a syntactically similar line of code, but the method API is very clear and intuitive.

If my method is:
Html.Textbox(string, string, object), that’s still confusing. What the heck is “object”? I’d rather see.

Html.Textbox(string, string, TextboxAttributes)
wekempf 1:41 pm on February 11, 2008

Now that I understand what this API is doing, and more specifically, what the “Defaults” property/parameter (it’s both) is for, this isn’t as misguided as I originally thought. Still the wrong solution, IMO, but I can understand it.

The “defaults” property has little meaning to the framework. It’s strictly a property bag or key/value collection that’s used to provide default values for “page parameters” (for lack of a better term) when they aren’t supplied in the URL. I can even see how this usage could be optimized to be efficient, even though reflection would need to be used. The meaning of the code isn’t any less obvious when you use an anonymous object than it is when you use a Dictionary.

That said, the only reason to be using the anonymous type is to simplify the calling code. However, I don’t find that to be a compelling reason to use an anonymous type here. A DefaultValues dictionary type would add very little syntactically to the calling site. The benefit here is minimal at best. Since the Dictionary solution will perform the best here, I don’t agree with the use of the anonymous type.

Comments are closed.

Programming with Palermo

Jeffrey Palermo, Microsoft MVP, Author, Speaker, Clear Measure Chief Architect, Azure DevOps Expert

Use caution with anonymous types and other new C# language features

Related

Related

Discover more from Programming with Palermo