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 Carrero Blog: http://flanders.co.nz Google Wave: portocarrero.ivan at googlewave.com Twitter: http://twitter.com/casualjim Author of IronRuby in Action (http://manning.com/carrero) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20091117/49c765b3/attachment-0001.html>
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: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] 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? 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 Carrero Blog: http://flanders.co.nz Google Wave: portocarrero.ivan at googlewave.com<mailto:portocarrero.ivan at googlewave.com> Twitter: http://twitter.com/casualjim Author of IronRuby in Action (http://manning.com/carrero) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100105/e298c87a/attachment-0001.html>
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 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 Mon, Jan 4, 2010 at 7:33 PM, Jimmy Schementi < Jimmy.Schementi at microsoft.com> wrote:> 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:* ironruby-core-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *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? > > > > > 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 Carrero > Blog: http://flanders.co.nz > Google Wave: portocarrero.ivan at googlewave.com > Twitter: http://twitter.com/casualjim > Author of IronRuby in Action (http://manning.com/carrero) > > _______________________________________________ > 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/20100104/df5ec2b6/attachment.html>
> 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
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>
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. ~Jimmy _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org<mailto: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/20100107/cf10fc83/attachment.html>