[Ironruby-core] when do we get this?

Jimmy Schementi Jimmy.Schementi at microsoft.com
Wed Jan 6 22:38:47 EST 2010

I believe it’s in there not, but I don’t have any samples of it handy.

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Ryan Riley
Sent: Tuesday, January 05, 2010 7:31 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] when do we get this?

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<mailto: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<mailto: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.

Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100107/cf10fc83/attachment.html>

More information about the Ironruby-core mailing list