[Ironruby-core] when do we get this?
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?
Email: ryan.riley at 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
> 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
> > to late-bind to properties, right? I might be wrong on that, but I know
> > can bind to an interface and get to all the properties of the
> > 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
> the Ruby "view" of the world, and therefore WPF/Silverlight
> binding doesn't work. Again, the methods and classes defined in Ruby are
> 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
> I showed at RailsConf databinding a WinForms GridView to an ActiveRecord
> 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
> 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ironruby-core