When C# Dresses Up Like Ruby | Hacker News Reader

When C# Dresses Up Like Ruby

blog.wekeroad.com

43 pointsrobconery13 comments

I've never once used the dynamic keyword in a C# program, but I do ponder on it a lot. The new dynamic features in C# being able to provide a "method_missing" along with the emphasis on "what it does" over "what it is" is really intriguing to me. Can this be leveraged in any meaningful way in C#? Has anyone given it a real try yet? If so, should we even bother? Why not just stick with a language like Ruby then? It feels awkward to say the least to start doing this in a language like C#. Although most C# apps dive into reflection quite a bit to pull off similar functionality.

I am currently working on a Silverlight app using RIA Services. Here on the server side you have to have each CRUD method for each type you are surfacing. You can't do

        public IQueryable<T> Get<T>() { }

It has to be

        public IQueryable<Foo> GetFoos() { }
        public IQueryable<Bar> GetBars() { }

Same with all update, insert and delete methods. It drives me insane that I literally have several thousand lines of CRUD methods. Can some kind of dynamic solution jump in here and help? I doubt it, but I can dream. (Generics don't work here because RIA services can't support sending generic arguments across the wire).

That depends on what the GetFoos are doing. Why couldn't you do IQueryable<ISerializable>?

What I really like about the dynamic features of C# is that dynamic objects are not just simply expando objects; you can write your own dynamic object implementations and specify their behaviour. You can create dynamic types that behave like types in various other languages which is very useful when you're trying to interface code from those languages.

F#'s dynamic support is more interesting than C#. Instead of giving you yet more special-case compiler rules, F# provides dynamic lookup and assignment operators, but you provide the implementation. That way you can implement what you'd like to happen in the scenarios where you want dynamic access with convenient syntax.

I've found MS's less-typed APIs like MVC to be more annoying to use. Taking "object" everywhere? Just means the tools (IntelliSense/compiler) can't provide the info I need, and I'm forced to go read documentation for small things.

Especially silly is the whole "use an anonymous type as a dictionary" idea. (E.g, SomeFunction(new { width=100, height=200, style="bla"}). The only reason I can see a need for this is because the language doesn't have handy list/sequence and tuple syntax.

There are good places for using dynamic typing. Unfortunately, it seems MS is mainly doing it for interop and as a patch for other annoyances.

What are you talking about?

In C# you can make your objects implement IDynamicObject with this signature ...

     public interface IDynamicObject {
          MetaObject GetMetaObject(Expression parameter);
     }

That returned MetaObject is responsible for defining the runtime dispatching, and you can do it however you want. The "binders" defined in MetaObject are returning Expressions, which means that the DLR library also has a chance to do inline caching.

F# uses the same API.

> Just means the tools (IntelliSense/compiler) can't provide the info I need, and I'm forced to go read documentation for small things.

Yeah, reading documentation in this day and age. The horror!

Interesting, thank for the info on that interface. F# doesn't use that though; it simply has syntax support for a user-defined dynamic operator. That is, I can do foo?bar and I'll get bar as a string and do what I please. The types you mention don't even appear in the F# compiler source.

As far as reading documentation, I shouldn't be forced to lookup tiny things here and there because an API decides to use object type for each parameter.

It is definitely neat that you can take a language like C# and make it dynamic... but it would seem to be a lot more sane to just use the IronPython or IronRuby, or even the plain Python or Ruby runtimes themselves. Use a language for what it's good at?

Part of the reason dynamic exists is to integrate with dynamic languages like Iron* in a saner way. This allows you to use C# for what it is good for, Ruby for what it is good for, and cleanly integrate the two.

What's the rationale for adding dynamic typing to C#?

Is it only to support interop with dynamic languages (Iron*)?

I'm not against the idea but it seems like a minor use-case to add a major language feature for. Unless there's something else I'm missing.

In the past, C# added new language features in order to support some specific goal.

Extension methods, lambdas and expression trees were added mainly to support LINQ. They're good features on their own, for sure, but the reason they were added is because the language team wanted to do LINQ.

What's the larger goal here?

I've tried to come up with which use-cases make sense for C#'s dynamic as well.. Where I mostly could figure that it would really help is with COM interop. Working with something like MS Office is fairly painful in C#3, since you have to pass the "Missing" argument to each of the 20-30 arguments that every method can take, and cast the result of every method.. The named arguments feature would also be useful there.

I've been fortunate enough to avoid having to interop with COM that directly recently, so haven't had to find out whether or not it makes a difference.

I just looked this up on Jon Skeet's website, and apparently he doesn't know either. Here is a lively thread where he posed the question to his readers:

http://msmvps.com/blogs/jon_skeet/archive/2009/11/17/where-d...

Serialization benefits massively - maybe the framework devs wanted it or perhaps its just about staying ahead of the curve.

I know in C# 5 they're planning on adding compilers as a service - the dynamic keyword might be necessary for that scenario but I'm not sure why the existing implicit typing system wouldn't work either.

COM interop is a popular culprit for this subject too.

Another possibility, although one that is somewhat dimmed by the virtual demise of Iron* within Microsoft, is that Microsoft wanted C# to be able to interop with other dynamic languages like IronRuby and IronPython. I can imagine a scenario where an IronRuby application could pass off a dynamically typed object to a shared library implemented in C# which supported DLR (dynamic language runtime) for some set of common functionality. I don't know much about what's possible today with respect to CLR objects passing between the DLR and the statically typed portions of the CLR, but I figured it was worth hazarding a guess.

Reply on news.ycombinator.com