When do we get this?

Ruby IronRuby
1

http://devhawk.net/CommentView,guid,cef44285-b9e7-47c3-84b6-d79833c76875.aspx

the question with regards to ironruby is when/if ? :slight_smile:

That sounds like it could be useful.

Met vriendelijke groeten - Best regards - Salutations
Ivan Porto C.
Blog: http://flanders.co.nz
Google Wave: [email protected]
Twitter: http://twitter.com/casualjim
Author of IronRuby in Action (http://manning.com/carrero)

2

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: [email protected]
[mailto:[email protected]] 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 ? :slight_smile:

That sounds like it could be useful.

Met vriendelijke groeten - Best regards - Salutations
Ivan Porto C.
Blog: http://flanders.co.nz
Google Wave:
[email protected]mailto:[email protected]
Twitter: http://twitter.com/casualjim
Author of IronRuby in Action (http://manning.com/carrero)

3

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: [email protected]
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 S. <

4

Thanks for the response, Jimmy. That really clears things up. So
IDynamicObject binding is in SL4 now or planned for release?

Ryan R.

Email: [email protected]
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 S. <

5

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

6

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

From: [email protected]
[mailto:[email protected]] On Behalf Of Ryan R.
Sent: Tuesday, January 05, 2010 7:31 AM
To: [email protected]
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: [email protected]mailto:[email protected]
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 S.
<[email protected]mailto:[email protected]>
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
[email protected]mailto:[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core