Hi Joe, > Shared DynamicSites don't get initialized for each specific class/object > and method combination.
I know; that's why I mentioned "initialized" was probably the wrong term to use. What I meant was that at some point in time, there would be a rule created for a given class/method combination and somehow associated with that DynamicSite. > Keep reading the code -- RubyBinder.cs in the Ruby project and > DynamicSite.cs in the Microsoft.Scripting project -- to see how this > happens for IronRuby. RubyBinder.cs should answer your question about > why the behavior is different between InvokeMember and ConvertTo. > Briefly, the Ruby action binder applied different rules to these > invocations. That was pretty obvious. even to; but not really my point. > Maybe one day someone with more acumen and expertise than myself will > write a book about how the DLR works internally like what Don Box, Jeff > Richter, and others did for the CLR. It'll be easier to comprehend > then. In the meantime, you'll just have to rough it on the bleeding > edge. ;) I wasn't particularly asking about the DLR internals; this isn't really the place to do that anyway (not that there's actually one), but rather about IronRuby's use of it, and more specifically aimed at understanding a bit better how the library implementations got hooked into the runtime for their corresponding classes. I probably don't need to understand it anyway, but I prefer to. -- Tomas Restrepo http://www.winterdom.com/weblog/ _______________________________________________ Ironruby-core mailing list [email protected] http://rubyforge.org/mailman/listinfo/ironruby-core
