Thanks for the response, Jimmy. That really clears things up. So IDynamicObject binding is in SL4 now or planned for release?
Ryan Riley Email: ryan.ri...@panesofglass.org LinkedIn: http://www.linkedin.com/in/ryanriley Blog: http://wizardsofsmart.net/ Twitter: @panesofglass Website: http://panesofglass.org/ On Tue, Jan 5, 2010 at 2:28 AM, Jimmy Schementi < jimmy.scheme...@microsoft.com> wrote: > > Interesting. I thought that technique was only providing an underlying > > "anonymous .NET base class" for binding purposes, much as IronRubyInline > > could offer but without having to write any C#. I guess I was mistaken. > > You're actually correct. The IronPython clrtype feature simply allows you > set > the underlying CLR type that a Python class maps to. The examples that > Harry built and Shri is currently maintaining build on top of that feature > to provide helpers for customizing that underlying type, mainly taking the > dynamic view of the world and make it static. This feature needs to exist > because a CLR type is immutable, so the language needs to give user-code > a chance to create the CLR type first. > > > Also, IronRuby does have types and WPF/Silverlight binding uses > reflection > > to late-bind to properties, right? I might be wrong on that, but I know > you > > can bind to an interface and get to all the properties of the > implementation, > > even those not defined on the interface. Couldn't that be leveraged for > > IronRuby objects? > > A Ruby class does not map to a CLR type, so reflection does not work > against > the Ruby "view" of the world, and therefore WPF/Silverlight > reflection-based > binding doesn't work. Again, the methods and classes defined in Ruby are > not > mirrored as CLR objects, they only exist in IronRuby's data-structures. So > reflection-based data-binding is out of the question for pure Ruby code. > > However, IronRuby.Builtins.RubyObject implements ICustomTypeDescriptor on > the desktop CLR, which allows IronRuby to expose Ruby methods to data > binding; > I showed at RailsConf databinding a WinForms GridView to an ActiveRecord > model. > However, SL3 does not have this interface, so data binding in SL3 is only > reflection-based. SL4 has IDynamicObject data-binding, so this won't be an > issue at that time. > > > Actually, I've been confused on this point awhile: aren't all IronRuby > > objects implementations of RubyObject? > > Sometimes =P a Ruby class that only has other Ruby class in its inheritance > hierarchy > will have a underlying CLR type of IronRuby.Builtins.RubyObject: > > >>> Object.new.GetType > => IronRuby.Builtins.RubyObject > > However, if there is a CLR type in the inheritance hierarchy, the > underlying > CLR type will be generated in the IronRuby.Classes namespace: > > >>> class MyDict < System::Collections::Generic::Dictionary[String, String] > ... end > => nil > >>> MyDict.new.GetType > => IronRuby.Classes.Dictionary`2$1 > > Note how long that MyDict.new take to be created, which is entirely > attributed to > the cost of generating a new CLR type. > > ~Jimmy > _______________________________________________ > Ironruby-core mailing list > Ironruby-core@rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core >
_______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
