> 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
