# When do we get this? **URL:** \ **Category:** IronRuby\ **Created:** [November 17, 2009, 6:32pm UTC](https://www.ruby-forum.com/t/when-do-we-get-this/179102 "2009-11-17T18:32:02Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![barby](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/c57346/32.png) [@barby](https://www.ruby-forum.com/u/barby)\ **Post date:** [November 17, 2009, 6:32pm UTC](https://www.ruby-forum.com/t/when-do-we-get-this/179102/1 "2009-11-17T18:32:02Z")
[http://devhawk.net/CommentView,guid,cef44285-b9e7-47c3-84b6-d79833c76875.aspx](http://devhawk.net/CommentView,guid,cef44285-b9e7-47c3-84b6-d79833c76875.aspx) the question with regards to ironruby is when/if ? 🙂 ## That sounds like it could be useful. Met vriendelijke groeten - Best regards - Salutations Ivan Porto C. Blog: [http://flanders.co.nz](http://flanders.co.nz) Google Wave: removed\_email\_address@domain.invalid Twitter: [http://twitter.com/casualjim](http://twitter.com/casualjim) Author of IronRuby in Action ([http://manning.com/carrero](http://manning.com/carrero)) ---
**Author:** ![barby](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/c57346/32.png) [@barby](https://www.ruby-forum.com/u/barby)\ **Post date:** [January 5, 2010, 2:35am UTC](https://www.ruby-forum.com/t/when-do-we-get-this/179102/2 "2010-01-05T02:35:07Z")
Controlling the “static” view of IronRuby is an inevitable feature, though I’m not sure when we’ll get around to implementing it … definitely after 1.0 though. This type of feature opens a whole can of worms, and for me even prompts the question, “should IronRuby have optional static typing?” From: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Ivan Porto Carrero Sent: Tuesday, November 17, 2009 9:22 AM To: ironruby-core Subject: [Ironruby-core] when do we get this? > **[DevHawk – DevHawk](https://devhawk.net/CommentView,guid,cef44285-b9e7-47c3-84b6-d79833c76875.aspx)** the question with regards to ironruby is when/if ? 🙂 ## That sounds like it could be useful. Met vriendelijke groeten - Best regards - Salutations Ivan Porto C. Blog: [http://flanders.co.nz](http://flanders.co.nz) Google Wave: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Twitter: [http://twitter.com/casualjim](http://twitter.com/casualjim) Author of IronRuby in Action ([IronRuby in Action - Ivan Porto Carrero and Adam Burmister | Manning](http://manning.com/carrero)) ---
**Author:** ![barby](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/c57346/32.png) [@barby](https://www.ruby-forum.com/u/barby)\ **Post date:** [January 5, 2010, 6:15am UTC](https://www.ruby-forum.com/t/when-do-we-get-this/179102/3 "2010-01-05T06:15:16Z")
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. 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? Actually, I’ve been confused on this point awhile: aren’t all IronRuby objects implementations of RubyObject? If so, what is it that prevents the type from being bound? I’m sure that’s already documented elsewhere, but I can never find the link when I go looking for it. Cheers! Ryan R. Email: removed\_email\_address@domain.invalid LinkedIn: [http://www.linkedin.com/in/ryanriley](http://www.linkedin.com/in/ryanriley) Blog: [http://wizardsofsmart.net/](http://wizardsofsmart.net/) Twitter: @panesofglass Website: [http://panesofglass.org/](http://panesofglass.org/) On Mon, Jan 4, 2010 at 7:33 PM, Jimmy S. \< ---
**Author:** ![barby](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/c57346/32.png) [@barby](https://www.ruby-forum.com/u/barby)\ **Post date:** [January 5, 2010, 4:32pm UTC](https://www.ruby-forum.com/t/when-do-we-get-this/179102/4 "2010-01-05T16:32:14Z")
Thanks for the response, Jimmy. That really clears things up. So IDynamicObject binding is in SL4 now or planned for release? Ryan R. Email: removed\_email\_address@domain.invalid LinkedIn: [http://www.linkedin.com/in/ryanriley](http://www.linkedin.com/in/ryanriley) Blog: [http://wizardsofsmart.net/](http://wizardsofsmart.net/) Twitter: @panesofglass Website: [http://panesofglass.org/](http://panesofglass.org/) On Tue, Jan 5, 2010 at 2:28 AM, Jimmy S. \< ---
**Author:** ![barby](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/c57346/32.png) [@barby](https://www.ruby-forum.com/u/barby)\ **Post date:** [January 5, 2010, 9:29am UTC](https://www.ruby-forum.com/t/when-do-we-get-this/179102/5 "2010-01-05T09:29:00Z")
> 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 ---
**Author:** ![barby](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/c57346/32.png) [@barby](https://www.ruby-forum.com/u/barby)\ **Post date:** [January 7, 2010, 4:39am UTC](https://www.ruby-forum.com/t/when-do-we-get-this/179102/6 "2010-01-07T04:39:12Z")
I believe it’s in there not, but I don’t have any samples of it handy. From: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Ryan R. Sent: Tuesday, January 05, 2010 7:31 AM To: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 R. Email: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) LinkedIn: [http://www.linkedin.com/in/ryanriley](http://www.linkedin.com/in/ryanriley) Blog: [http://wizardsofsmart.net/](http://wizardsofsmart.net/) Twitter: @panesofglass Website: [http://panesofglass.org/](http://panesofglass.org/) On Tue, Jan 5, 2010 at 2:28 AM, Jimmy S. \<[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)\> 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 [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core)