http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Darius is right, __getattr__ in Python got exactly the same behavior which makes sense. I was missing this behavior a lothttp://ayende.com/119809/dynamic-resolution-rules-joy#comment24http://ayende.com/119809/dynamic-resolution-rules-joy#comment24Tue, 25 Oct 2011 15:57:24 GMTI think JC summed up this post, that the method is named very poorly. That if the method was named TryGetMissingMember that the intent would be conveyed properly.http://ayende.com/119809/dynamic-resolution-rules-joy#comment23http://ayende.com/119809/dynamic-resolution-rules-joy#comment23Mon, 24 Oct 2011 13:54:20 GMTStandard behaviour, if I remember correctly, Python does exactly the same, and that makes perfect sensehttp://ayende.com/119809/dynamic-resolution-rules-joy#comment22http://ayende.com/119809/dynamic-resolution-rules-joy#comment22Sun, 23 Oct 2011 08:06:37 GMTI believe the confusion comes from prior experience with Dynamic Proxies. one should understand that dynamic proxies and dynamic object are different. the behavior you are expecting is very reasonable in a dynamic proxy scenario. it is less reasonable in a dynamic object.http://ayende.com/119809/dynamic-resolution-rules-joy#comment21http://ayende.com/119809/dynamic-resolution-rules-joy#comment21Sat, 22 Oct 2011 18:10:47 GMTSeems fitting that it would infer the explicit assignment first, then fall through to an implicit when unavailable.http://ayende.com/119809/dynamic-resolution-rules-joy#comment20http://ayende.com/119809/dynamic-resolution-rules-joy#comment20Sat, 22 Oct 2011 17:43:53 GMTAgree with Michael. This is the behavior I would expect. http://ayende.com/119809/dynamic-resolution-rules-joy#comment19http://ayende.com/119809/dynamic-resolution-rules-joy#comment19Fri, 21 Oct 2011 19:54:32 GMTMaybe the method should have been named TryGetMissingMember instead hence avoiding any confusion about it's functionality.http://ayende.com/119809/dynamic-resolution-rules-joy#comment18http://ayende.com/119809/dynamic-resolution-rules-joy#comment18Fri, 21 Oct 2011 17:06:52 GMTThis is standard behavior for any dynamic language. Smalltalk's doesNotUnderstand is only called if the object is sent a message that it does not understand. Ruby's method_missing is only called when a method is truly missing. I think it would be more annoying if .NET were to choose the opposite default.http://ayende.com/119809/dynamic-resolution-rules-joy#comment17http://ayende.com/119809/dynamic-resolution-rules-joy#comment17Fri, 21 Oct 2011 16:21:02 GMTIt seems like what you want is to use the dynamic behavior to essentially override a default value for some property: the only time you want to get the actual property value would be if nothing had been assigned. So the "setter" seems quite pointless if you expect the dynamic behavior to take precedence. So why not just create a default dynamic value instead of a property? E.g. in your constructor just call TrySetMember to add some default for a dynamic value, instead of hardcoding a property that you want to allow to be overridden. I think this makes sense, but if you don't like it, then just implement your own IDynamicMetaObjectProvider. http://ayende.com/119809/dynamic-resolution-rules-joy#comment16http://ayende.com/119809/dynamic-resolution-rules-joy#comment16Fri, 21 Oct 2011 14:44:14 GMTJust proves that however logical an API appears to be, there is always someone who doesn't like it the way it is. I like that as a sort of comforting start of weekend thought.http://ayende.com/119809/dynamic-resolution-rules-joy#comment15http://ayende.com/119809/dynamic-resolution-rules-joy#comment15Fri, 21 Oct 2011 13:59:01 GMT@zdeslav: public override bool TryGetMember(GetMemberBinder binder, out object result) { if(binder.StaticInvoke!=null) return binder.StaticInvoke(out result); } Still I think the current design is better, but it wouldn't have to be as bad as you are assuming.http://ayende.com/119809/dynamic-resolution-rules-joy#comment14http://ayende.com/119809/dynamic-resolution-rules-joy#comment14Fri, 21 Oct 2011 13:34:43 GMTI think the confusion lies in that people assume that the dynamic keyword and the DynamicObject type are somewhat related - they aren't (they just happen to be used together lots of times). It makes sense to me that you get the 'statically-defined' member rather than the result of TryGetMember. It most closely resembles 'normal' inheritance - start with the object and work up the inheritance tree until you find member you are looking for. (The dynamic keyword just kets you late-bind to the object and thus make it 'more readable' as a simple member.)http://ayende.com/119809/dynamic-resolution-rules-joy#comment13http://ayende.com/119809/dynamic-resolution-rules-joy#comment13Fri, 21 Oct 2011 12:35:03 GMTseems completely logical to me. Imagine: public class Stupid : DynamicObject { public int Age { get; set; } public int OtherProperty { get; set; } public int AndAnother { get; set; } ... public override bool TryGetMember(GetMemberBinder binder, out object result) { // if this would have precedence over the specified properties // here you would have to filter all of those properties // that would render explicit properties quite useless // if(binder.Name == "Age" ... } } http://ayende.com/119809/dynamic-resolution-rules-joy#comment12http://ayende.com/119809/dynamic-resolution-rules-joy#comment12Fri, 21 Oct 2011 12:00:35 GMTI've never used dynamic object at all, nor read much about it. Intuitively I would expect the getter t8o take precedence.http://ayende.com/119809/dynamic-resolution-rules-joy#comment11http://ayende.com/119809/dynamic-resolution-rules-joy#comment11Fri, 21 Oct 2011 11:49:55 GMTReading the MSDN link for DynamicObject.TryGetMember (http://msdn.microsoft.com/en-us/library/system.dynamic.dynamicobject.trygetmember.aspx), I found this inside the remarks block: "You can also add your own members to classes derived from the DynamicObject class. If your class defines properties and also overrides the TrySetMember method, the dynamic language runtime (DLR) first uses the language binder to look for a static definition of a property in the class. If there is no such property, the DLR calls the TrySetMember method.". So, the behaviour encountered inside the code above seems to be the correct one and is similar to the one described by the official documentation.http://ayende.com/119809/dynamic-resolution-rules-joy#comment10http://ayende.com/119809/dynamic-resolution-rules-joy#comment10Fri, 21 Oct 2011 11:14:40 GMTThis comes from the "Remarks" section of the MSDN article on TryGetMember: "You can also add your own members to classes derived from the DynamicObject class. If your class defines properties and also overrides the TrySetMember method, the dynamic language runtime (DLR) first uses the language binder to look for a static definition of a property in the class. If there is no such property, the DLR calls the TrySetMember method." 3 it is... or am I missing something?http://ayende.com/119809/dynamic-resolution-rules-joy#comment9http://ayende.com/119809/dynamic-resolution-rules-joy#comment9Fri, 21 Oct 2011 11:13:59 GMTI find that quite annoying as well, that if I want to use a dynamic object's property I have to cast it before passing it into any method. In my eyes that defeats the purpose of using a dynamic to begin with since it has that additional development overhead/noise. Maybe they can fix it in the next .Net where it can inspect the parameter type of the method and just try to do a best guess auto-cast.http://ayende.com/119809/dynamic-resolution-rules-joy#comment8http://ayende.com/119809/dynamic-resolution-rules-joy#comment8Fri, 21 Oct 2011 11:09:59 GMT@Ayende I find this behaviour normal. The notion of TryXXX (found when parsing numbers or getting stuff out of dictionaries) is related to uncertainty. Thus, if the CLR sees a getter, it should call that getter and not call the TryGetMember method.http://ayende.com/119809/dynamic-resolution-rules-joy#comment7http://ayende.com/119809/dynamic-resolution-rules-joy#comment7Fri, 21 Oct 2011 11:08:42 GMTMSDN article on TryGetMember is completely misleading - had I read it before posting my comment I would've expected 1 indeed.http://ayende.com/119809/dynamic-resolution-rules-joy#comment6http://ayende.com/119809/dynamic-resolution-rules-joy#comment6Fri, 21 Oct 2011 11:05:46 GMTSeems perfectly reasonable to me. I'd consider it stupid if it had printed 1.http://ayende.com/119809/dynamic-resolution-rules-joy#comment5http://ayende.com/119809/dynamic-resolution-rules-joy#comment5Fri, 21 Oct 2011 11:05:30 GMTSo what did you actually expect it to show? 3 is printed as I would've expected it.http://ayende.com/119809/dynamic-resolution-rules-joy#comment4http://ayende.com/119809/dynamic-resolution-rules-joy#comment4Fri, 21 Oct 2011 10:55:53 GMTBecause the whole point of dynamic is to get in control of the members that your object demonstrates to have.http://ayende.com/119809/dynamic-resolution-rules-joy#comment3http://ayende.com/119809/dynamic-resolution-rules-joy#comment3Fri, 21 Oct 2011 10:53:06 GMTWhy should it go the slower route of dynamic/reflection when there is a simple fast property on the object?http://ayende.com/119809/dynamic-resolution-rules-joy#comment2http://ayende.com/119809/dynamic-resolution-rules-joy#comment2Fri, 21 Oct 2011 10:46:31 GMTNever worked with the DLR but I believe that DynamicObject is not the lowest level of abstraction. Maybe you can overrride this stupid behavior by overriding DynamicMetaObject GetMetaObject and returning a more well-behaved object.http://ayende.com/119809/dynamic-resolution-rules-joy#comment1http://ayende.com/119809/dynamic-resolution-rules-joy#comment1Fri, 21 Oct 2011 10:30:30 GMT