

When C# Dresses Up Like Ruby - robconery
http://blog.wekeroad.com/2010/08/09/csharps-new-clothes

======
city41
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).

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

------
DrJokepu
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.

------
MichaelGG
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.

~~~
bad_user
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!

~~~
MichaelGG
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.

------
DrJosiah
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?

~~~
troygoode
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.

------
statictype
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?

~~~
sciolistse
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.

