Charlie Calvert's Community Blog

What's the usability scope of the "dynamic" keyword?  If it's only inside method/property members, that will be quite limiting on its use.

The intention is indeed for this to be efficient. A big part of the DLR's job is to provide efficient execution infrastructure for code that is looked up at runtime - such as that of dynamic languages - Python, Ruby etc.

/Mads

@Charlie

Our typical use for late-binding was Interop/Office scenarios.  We would create a single class to act as a facade over these COM resources.

Sometimes COM classes can be expensive to instantiate.  In these cases, we would instantiate them at the constructor and set a private field.

Also, COM references would frequently cross method (but not class) boundaries as we would do normal internal refactoring.

For anything but dead simple scenarios, it would be difficult to accomplish what we need in one method.  As large as the Office interfaces are, there's not a whole lot you can accomplish inside a single block before it gets complex and unmaintainable.

In these cases, I wouldn't necessarily need namespace-scoping, but file or class scoping would be sufficient.

I have been searching for any clue about the next version of C# and what the features to be included,...

First of all, I think it is a great idea to give us an early insight in your future plans and let us give early feedback.

My suggestion is to limit the scope of the dynamic-block to a particular variable or property and also to allow it in the declaration of (local) variables or maybe even properties and fields. This is, because in most cases you don't want every lookup in your dynamic block to be dynamic, but only to some variables that e.g. contain COM-objects.

So in the example above, I would rather see:

object myDynamicObject = GetDynamicObject()

dynamic(myDynamicObject)

   {

       ...

   }

or:

dynamic object myDynamicObject = GetDynamicObject();

...

Of course something like myDynamicObject.Foo.Bar would also work, but something like:

object foo = myDynamicObject.Foo;

foo.bar

would not work and would require another dynamic modifier on the foo declaration.

If you allow the dynamic flag on property or public field declarations, you could do it with some sort of attribute, but I'm not sure if this is a good idea, because developers using these properties or fields may not be aware of the fact that they are opting in for dynamic lookup. Also this may encourage bad programming style, where someone exposes lots of "object"-properties and relying on the dynamic lookup, where he could use other mechanisms to give the caller a statically typed way to access these properties.

A compromise would be to allow this flag only in private property or field declarations, which would make a class scoped dynamic keyword (as suggested above) unnecessary and still allow for static typing for everything not marked dynamic in the class.

I would love to hear your feedback on this.

Finally, some news for next version coming up...

Interesting ..., i ll give my feedback ...

at first sight it seems to provide easy way for reflection...but there can be some interesting talks to it, like scoping or performance related..

Charlie Calvert has posted an article that is co-authored by Mads Torgerson on one possible implementation

Adding to the Scoping of the Dynamic Object. We too use the object at the class level. For example we write an export class that has a single handle into Excel. Having the scoping at the method level will severly limit the cross method calls. Unless we can declare the object as DynamicObject in the calling method.

private void CreateHeaders(dynamic object excelObject, string[] headers) {

dynamic(excelObject) {

}

}

Mmmm that sounds so VB... does it mean that the F# tunics have left the team and hand been replaced again by the VB Ties?  

What I don't understand:

If everything inside the "dynamic"-block uses  dynamic lookup, then you'll loose type safety for everything inside this block, not just the objects you're really needing it for. This is a much broader granularity IME than declaring a single object as dynamic and leaving all the other objects typesafe.

In a typical scenario you'll need every access to a specific object to be dynamic. If you just declare this single object dynamic, you'll have fewer dynamic lookups than having many dynamic blocks in a class that contain dozens of other objects that would normally be just fine with static lookup, but now use dynamic lookup, just because a single object in this block needs it.

Welcome to the fortieth issue of Community Convergence. This week we have two new releases of note: We

How about using -> instead of . for dynamic lookup? I'm only half joking!

If I understand what your doing, this is really just another C# compiler trick where your just going to replace it in IL with a reflection version.

If got that right, then I also prefer a new Dynamic Lookup method operator instead.

'->' might cause many C++ refuges some heartburn, so how about:

myLateBoundLocalObject'Method1()

or

myLateBoundLocalObject~Method1()

or

myLateBoundLocalObject@Method1()

or

myLateBoundLocalObject..Method2()

or even reverse it to make them stand out more

aka

Method1() of myLateBoundLocalObject

or

Method1()@myLateBoundLocalObject

I think if a good operator is found it would make the code much cleaner.

I personnally like the '..' version as it would be easy to remember.

One period for Static bound calls,

Two periods for Dynamic lookup.

-Pablo

Kinda OT, but since somebody important could be reading this...

Can we /please/ have something like ':' operator, so that following could be written:

string greatGrandFatherName = person:Parent:Parent:Parent:Name;

...instead of tedious...

if (person.Parent == null) return null;

if (person.Parent.Parent == null) return null;

if (person.Parent.Parent.Parent == null) return null;

return person.Parent.Parent.Parent.Name;

OK, this isn't the best example, but there are many uses for this (especially in ORM) and it makes syntax so much cleaner, IMHO.

LP,

Dejan

I often rethink or have additions to my posts. This topic of what's coming in C# vNext is definitely

This is so fun I have to put out another idea...

What about some kind of inline interface declaration?

object myObject = GetDynamicObject();

dynamic

{

 interface (myObject)

 {

   void SomeMethod();

   int GetSquare(int v);

 }

 catch

 {

 }

 myObject.SomeMethod();

 int i = myObject.GetSquare(100);

}

This way you both declare a dynamic section and declare the exact members you need.

There's actually no real late binding, just a syntactic sugar for reflection lookups.

Another nice feature here I think is the possibility to catch if the lookup fails.

You could even start a new interface failover declaration inside the catch.

After posting the -> 'suggestion' I decided that '..' would be a reasonable looking alternative. So there you have it - independent evolution of the same syntax idea from multiple people - it must be a good idea :)

The whole thing reminds me a bit of the old VB syntax for accessing fields on a recordset:

Sn!FieldName 'instead of Sn.Fields("FieldName")

Wouldn't it be cool to support both late binding and intellisense.

I think optionally declaring methods and properties in the variable declaration could do.

public class Program

{

// Without intellisense

dynamic object dynObject = GetDynamicObject();

// With intellisense

dynamic object dynObject = GetDynamicObject()

{

void SomeMethod();

}

}

This way you can opt for intellisense according to own needs.

And it could also be possible to declare inline:

dynamic (dynObject)

{

int GetSquare(int value);

}

int i = dynObject.GetSquare(100);

I hope this just uses reflection under the hood and doesn't alter the .NET framework to accomodate late binding in anyway. Much like var in C# is just a compiler trick

I do this today by using a PythonEngine instance in my C# applications. It's clunky but it works. The PythonEngine instance acts as the scope for the dynamic code. I can inject scripts into the engine using Execute() and fetch objects from the engine with Evaluate(). I use this sort of "dynamic layer" at the lower edge of my client applications to dynamically generate ClientBase<T> derived instances from WS-MetadataExchange using classes from the System.ServiceModel.Description and System.CodeDom namespaces. Imagine a SVCUTIL-free lifestyle. No proxy generation at all. It's nirvana, really.

I like Thomas Krause's proposed model where the objects to be used within a dynamic scope could be obtained outside of that scope because it would make what I'm doing with Python embedded in C# much simpler. Of course, I probably wouldn't be using Python to glue the WCF clients and services together with C# 4.0 if it supported what Charlie's talking about. But it would need to be done as Thomas describes to make it really fluid. Thomas' reply on 28 Jan at 13:29 seems to indicate that the C# team might be leaning this way. And that's good because the main problem I have today is making the dynamic Python code reach out of the dynamic scope to access object references obtained in the static scope. It's possible but really messy.

While I'm in here and on the topic of language futures, how about a policy attribute that I can attach to a class that forces it to be instantiated within a using statement? In other words, for a class that implements IDisposable, give me an attribute that I can mark the class with so that any attempt to instantiate the class in a way that would not invoke IDisposable::Dispose would simply not compile. Man, would that be helpful?!

- Kevin

Kudos to Brian for editing everything last night, I think he&#39;s sleeping on my couch right now, but

Personally, I have to side with the guys that like C# to stay static.  LINQ is about the extent of "dynamic-ness" that I can tolerate.  

Class Libraries written in IronPython callable by C#?  I honestly can't see many truly indispensible class libraries written in IronPython that couldn't otherwise be rewritten in a much more performant way in C#.  

Granted, usability is key here, but are we in the community asking for this?  My assertion is "USE VB" since VB frankly is so close to C#, yet still has the late binding techniques built in.

Eric, I understand your thinking about keeping C# statically typed. I sometimes wonder if the current duck typing pendulum has just swung to the far end of its period as it's known to do every few years. But I don't think so. This time, I think there is enough maturity in the marketplace that people are beginning to wonder why they can't have the best of both worlds.

My response above about my experiences embedding Python in C# is an expression of the fact that I love the type safety of C# most of the time. But when it's time to do something dynamic, I regret having to step out of C# (or into deep reflection and lots of CodeDom trickery) to do it.

Speaking of performance: for the dynamically-generated ClientBase<T> invocation of a WCF service in a tight loop versus using a statically-bound, SvcUtil-generated proxy called directly from C# that I described above, there is no difference in performance. The only real difference is that I never had to use SvcUtil in the former case and I really like that. So I can envision a world where static, early-binding and dynamic, late-binding get along just fine.

This is an exciting feature.  I have several comments.

1. I really like the .. operator idea either instead of or in addition to a dynamic block.  This is even more important in a maintainence scenerio than in new code.  If one is adding 2 dynamic calls to some existing code the choices are a) 2 dynamic blocks or b) subtly changing the semantic of all the method calls between them.  I really want more control over when I use dynamic invocation.

2. I hope you will expose the the name lookup logic through system.Reflection as well.  I have been trying to write a generic "accessor" class that uses reflection to allow unit tests to access private and protected members of production classes.  Doing the name resolution, based on a string member name, is easy to do wrong, and proving very difficult to do right.  I would enjoy being able to give reflection a name and say "find me the member, public / private  ... etc, that this name would map to."

3. WHat is going to happen when you do a Dynamic call on a RealProxy descendent.  I hope that it just calls Invoke with the method name and arguements, and lets me work it out.  (This would let me define some test objects with a very flexible interface.)

4. Add another vote for the : operator proposed by Dejan Stanic.  I see this pattern all the time, especially when using Linq.

John Melville

This is the kind of feature that should be introduced with extreme care, since a) it's too easy to implement (so the temptation to include it will be high, even if consequences have not been considered thoroughly) and b) if badly done, it can spoil forever our beloved language.

Strongly agree with others that a dynamic {} block is not the best solution, whether dynamic in that context means "every member access will be dynamically looked up" (too coarse-grained) or "access to members not found at compile time" (also coarse-grained and may complicate understanding of the code).

Explicitly supporting "dynamic" in front of "object" in declarations (as Daniel proposes) seems much better to me. For instance, in the example of wkhazzard one could define a method:

public class ProxyGen

{

 dynamic object GetProxy() { /*...*/ }

}

and then the client would use:

 ProxyGen p = new ProxyGen();

 dynamic object cli = p.GetProxy();

 cli..Whatever();

I also support having a special operator (I'd prefer ->, but it's already used in unsafe blocks), so that these dynamic method calls are explicitly marked in code.

Best regards,

Octavio

Give us an interface we can implement on our own classes that allows us to implement method dispatch! The Boo lanaguage has IQuackFu - silly name but very powerful.

Something like this would be cool for C#:

class MyFoo : IDynamicDispatcher

{

  object IDynamicDispatcher.Invoke(string methodName, object[] args)

  {

     // ...

  }

  // similar for properties here...

}

then use as:

dynamic foo = new MyFoo()

foo.Bar()

Compiler translates into:

foo.Invoke("Bar", null);

First impression:

WOW

Second impression:

I am not entirely sure... i still go "wow" but I have maybe a few concerns. The dynamic{} code might look a bit awkward. Also what about totally prototype like code, like where objects are not tied to a particular class, but instead can be shaped lateron? And aside from this, what happens when objects are modified or extended at runtime, can these changes be reflected back upon the C# world?

Anyway dont get me wrong, so far it looks great

For all the reasons Eric mentioned, and then some, please tread softly here. If you really need to do this, you can already do this. Make it too easy, and you'll have every idiot who thinks code reuse is done with ctrl-c,ctrl-v making every single call dynamically. This is the problem we currently have where people use generics willy-nilly thinking they are writing code in a generic fashion, not realizing what the compiler does when it comes across generics.

Speaking of generics, how do they match up with dynamic? Bit of an interesting topic, I'm sure.

Also, performance, performance, performance. The word Dynamic translates into "trading performance for developer convenience" in just about every case you come across. A lot of developers don't make the connection that doing things dynamically makes for extra load at run time most of the time.

Charlie Calvert blogged about dynamic support in C# 4.0 . I love this for two reasons. One it will enable

I agree with David. I use C# because it is statically typed. That is also why I stay away from VB and languages like IronPython etc. I do *not* want dynamic code in my C# code.

Carlie Calvert wrote:

"Please note that the proposed C# features discussed in this post are not designed to convert C# into a dyanmic language, only to make it possible to call code written in a dynamic language and to make COM interop simpler."

Understood. However, it should be put in a library, not built into the language. I think that reflection is sufficient, but now that we have the DLR, just extend it as needed.

Any chance of having a similar keyword in Visual Basic?  It's neat that I can already make dynamic calls in VB, but I believe it currently requires one to turn Option Strict Off.  Something more fine grained would be awesome.

Quote: "Now comes "dynamic lookup". Again, nothing that I can not already do with reflection"

Might I suggest assembly language? There's nothing you can't do in it, and there's none of that nasty 'syntactic sugar' you seem to object to. Seriously.

I also strongly agree with Thomas.  

I'll also throw one other option into the mix.  What about something like this

object myDynamicObject = GetDynamicObject();

myDyamicObject."SomeMethod"();

The quotes around the method name make it clear that, as far as the compiler is concerned, the name of this method is just a string, to be looked up at runtime.

To me, the main thing is to find something that doesn't require a block to be wrapped around the code, and which lets me (any my IDE's syntax highlighing) tell exactly which calls are dynamic - either by the variable they are made against (as in Thomas's suggestion) or by the way the call is written.

Based on my experience with VB (which really already has this), I agree with Thomas & Miguel. Blocks are the wrong granularity.  Either variable or call level would be great.

@Charlie - "The idea of declaring an entire object as dynamic is also in play, but there is a concern that a broad granularity of that type is not right for C#."

I couldn't disagree more. Declaring an entire block to be dynamic is what is too broad. Declaring a single object is a more narrow approach that allows the developer to target the dynamic calls more appropriately. Perhaps even forcing individual calls to be made using a dynamic syntax would be the right way to go. But forcing a developer to use a dynamic block every time they want to make a dynamic call just makes the code harder to read.

@Thomas - "If everything inside the 'dynamic'-block uses  dynamic lookup, then you'll loose type safety for everything inside this block..."

@Charlie - "...the team is considering first attempting to resolve all code in a dynamic block statically, and using dynamic lookup only if the static calls can't be resolved at compile time."

You're talking about early binding; Thomas is talking about type safety. They are two different things. Sure, you can still early bind to anything that is statically accessible; but for anything that is not, you turn it into a dynamic call. So the developer has no way of knowing that when he mistyped that method name, instead of getting a compiler error, it gets turned into a dynamic call instead, which results in a run-time error.

The more I think about this whole thing, the more I think it is a bad idea that will lead to long-term negative consequences. Giving developers a way to easily lookup and execute dynamic calls at runtime is a good idea; baking into the syntax of the language is not. Can you please explain why you feel it is necessary to make it a part of the language, when you could just make it a part of the reflection library, or its own library, and it would function just as well, not to mention be useful in other languages as well?

I'd much rather see something like this (as others have already stated)

dynamic myDynamicObject = GetDynamicObject();

       myDynamicObject.SomeMethod();      

       myDynamicObject.someString = "value";

       myDynamicObject[0] = 25;

or perhaps

[dynamic] IMyInterface myDynamicObject = GetDynamicObject();

The block idea is a bad idea in my opinion.  I'm sure it's easier to implement, but is that good for the language in the long run?

Lots of ideas, issues, problems, solutions...

Its actually good taking feedback from community - such brainstrorming would help in getting it right the first time - a must for a language feature like this.

I too have my suggestion:

/// start

// define an interface normally as we do now

interface theDynamicObjectInterface

{

   void SomeMethod();

   int theProperty {get; set;}

}

// Something of this sort we do currently as:

//

// theDynamicObjectInterface theDynamicObject = (ItheDynamicObjectInterface)new theDynamicObjectClass();

//

// the above syntax gives a runtime error "Unable to cast..." if iterface and class implementation do not match

//

// this behavior can be altered by an explicit interntion of developer as:

dynamic theDynamicObjectInterface theDynamicObject = GetDynamicObject();

// this syntax will automatically try to cast returned object as the specified interface and

// if there is an error, object will be set to null

// here after there are normal calls which otherwise also we do

if (theDynamicObject != null)

{

  theDynamicObject.SomeMethod();

  theDynamicObject.theProperty = 10;

}

/// end

I might me missing compiler internals here, but I guess the idea is communicated.

Points to note here:

1) One point resolution for member mapping, i.e. at the time of assigning object to specified interface

2) Full intellisense

3) No special delimiter required for call-to-call basis mapping (.. or ->, etc.)

4) No dynamic code block

Microsoft haven&#39;t committed to anything in C# 4 yet. However, there have been hints about what they&#39;ve

Heres an off topic question. Recently the C++ team has released a beta of the upcoming MFC changes. Included in this are some nice UI changes that incorrorate alot of the Office/Visual Studio UI enchancements, such as docking, theming, Ribbon Bar, and more...

Is there any plans to update WInForms to include these enchancements?

What a terrible idea. It seems like we keep taking this circular path with languages that takes us back to exactly where we started, but with new toys.

So much for type safety and code that can be analyzed by external tools for issues

Una vez salidos al mercado .NET 3.5 y C# 3.0, el equipo de desarrollo ya ha comenzado a pensar en las

So, the proposed block syntax might have two motivations that I can think of:

* It's for implementation/performance reasons. Some context will be built up and held within the block in order to perform the dynamic lookup. This can then be discarded when the block is exited. If this is the motivation then I think the syntax gets in the way of usage and any performance considerations should be 'hidden' and not emphasised in a block syntax.

* It's to deliberately demarcate dynamic lookup code so that programmers can see it being used. If this is the case then I can see the point. But at th