[Ironruby-core] when do we get this?

Ryan Riley ryan.riley at panesofglass.org
Tue Jan 5 10:31:15 EST 2010

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.riley at 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.Schementi at 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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100105/29a4472b/attachment.html>

More information about the Ironruby-core mailing list