Forum: IronRuby Should Kernel.require accept Assembly instances?

Posted by Charles Strahan (charles-strahan)
on 2010-08-07 00:09
(Received via mailing list)
What would you all think of having the ability to require a given 
Assembly?
I think this could be useful when compiling code in memory, in which 
case
there isn't a path to give Kernel.require.

If this is something we could all use, I'll open a ticket for it.

-Charles
Posted by Orion Edwards (Guest)
on 2010-08-07 12:37
(Received via mailing list)
What's the advantage to extending require?

Presumably you're currently using the .NET Assembly.Load or 
Assembly.LoadFrom methods to do this? (And if you're compiling code in 
memory, you'll certainly be making heavy use of the .NET reflection 
API's already anyway)

Require is a standard part of core ruby, and is meant to take paths.
While it's obvious to overload it to accept paths to dll's as well as rb 
files, overloading it to take non-path things (such as .NET assembly 
objects) seems like it's diverging a bit too far away from it's normal 
(ie: MRI ruby) use, and more into the realms of specific .NET 
extensions...
Posted by Charles Strahan (charles-strahan)
on 2010-08-09 19:01
(Received via mailing list)
Those are valid points. Perhaps #load_assembly could accept an
assembly reference.

Sent from my iPhone

On Aug 7, 2010, at 5:16 PM, Orion Edwards <orion.edwards@gmail.com>
Posted by Orion Edwards (Guest)
on 2010-08-09 23:28
(Received via mailing list)
I'm looking through the MSDN docs for assembly loading, and it seems as
though you can either load an assembly from a path, or from a byte 
array.
Both of these methods return an Assembly object.

There doesn't appear to be any other way to actually get an Assembly 
object
other than by loading it, as the constructor is protected (assembly is
abstract), and the only classes that I can see in the framework that 
derive
from it are the internal RuntimeAssembly class (which is used for 
everything
pretty much), and System.Reflection.Emit.AssemblyBuilder.

As far as I can infer, the only way to actual get an assembly object is 
to
load the assembly, so if you're asking how you can load an assembly 
given an
Assembly object... it's already loaded.

Am I missing something?

On Tue, Aug 10, 2010 at 4:49 AM, Charles Strahan <
Posted by Charles Strahan (charles-strahan)
on 2010-08-10 20:16
(Received via mailing list)
Orion,

Yes, I can use Assembly.LoadFrom to load an assembly from a path (and I 
am
doing that), but that's not *all* I want to do.  I think the easiest way 
to
communicate my intentions is to ask you the following question:

Q: What happens when I call Kernel.load_assembly in IronRuby, provided I
pass in some assembly name?

A: Modules are created that reflect the types and namespaces within the
assembly (::System::InteropServices, ::System::Reflection::Assembly, 
etc).

That's the effect I want.  If I just use Assembly.LoadFrom, IronRuby 
will
not treat that the same way as Kernel.load_assembly, nor should it.

Do you see where I'm going with this?


I thought I had found a way to hack around this by getting to the 
current
context with this little hack:

# ::Object is an instance of RubyClass, which holds a reference to the
RubyContext within which it was created.
# However, IronRuby hides the Context property, so you can't do
Object.context, Kernel.context, etc (which is a good thing).
# But, with a little reflection (and because I know Context really is
there), I can do the following:
context = Object.GetType.get_members.find { |m| m.name == 'Context'
}.get_value(Object, nil)

And then I figured I could do something like this:
context.loader.load_assembly(...)

... but the overload I need is marked private (the one that is public
expects a string containing the assembly's name, as opposed to path).  I
suppose I could use reflection again, but it wouldn't work without full
trust.  It was a cool idea, nonetheless.

-Charles
Posted by Tomas Matousek (Guest)
on 2010-08-10 20:44
(Received via mailing list)
I think it makes sense to add an overload for load_assembly that takes 
Assembly object instead of name. Charles, feel free to submit a patch or 
file a bug to trace the feature request and I'll get to it soon.

Tomas

From: ironruby-core-bounces@rubyforge.org 
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Charles 
Strahan
Sent: Tuesday, August 10, 2010 11:04 AM
To: ironruby-core@rubyforge.org
Subject: Re: [Ironruby-core] Should Kernel.require accept Assembly 
instances?

Orion,

Yes, I can use Assembly.LoadFrom to load an assembly from a path (and I 
am doing that), but that's not *all* I want to do.  I think the easiest 
way to communicate my intentions is to ask you the following question:

Q: What happens when I call Kernel.load_assembly in IronRuby, provided I 
pass in some assembly name?

A: Modules are created that reflect the types and namespaces within the 
assembly (::System::InteropServices, ::System::Reflection::Assembly, 
etc).

That's the effect I want.  If I just use Assembly.LoadFrom, IronRuby 
will not treat that the same way as Kernel.load_assembly, nor should it.

Do you see where I'm going with this?


I thought I had found a way to hack around this by getting to the 
current context with this little hack:

# ::Object is an instance of RubyClass, which holds a reference to the 
RubyContext within which it was created.
# However, IronRuby hides the Context property, so you can't do 
Object.context, Kernel.context, etc (which is a good thing).
# But, with a little reflection (and because I know Context really is 
there), I can do the following:
context = Object.GetType.get_members.find { |m| m.name<http://m.name> == 
'Context' }.get_value(Object, nil)

And then I figured I could do something like this:
context.loader.load_assembly(...)

... but the overload I need is marked private (the one that is public 
expects a string containing the assembly's name, as opposed to path).  I 
suppose I could use reflection again, but it wouldn't work without full 
trust.  It was a cool idea, nonetheless.

-Charles


On Mon, Aug 9, 2010 at 3:45 PM, Orion Edwards 
<orion.edwards@gmail.com<mailto:orion.edwards@gmail.com>> wrote:
I'm looking through the MSDN docs for assembly loading, and it seems as 
though you can either load an assembly from a path, or from a byte 
array. Both of these methods return an Assembly object.

There doesn't appear to be any other way to actually get an Assembly 
object other than by loading it, as the constructor is protected 
(assembly is abstract), and the only classes that I can see in the 
framework that derive from it are the internal RuntimeAssembly class 
(which is used for everything pretty much), and 
System.Reflection.Emit.AssemblyBuilder.

As far as I can infer, the only way to actual get an assembly object is 
to load the assembly, so if you're asking how you can load an assembly 
given an Assembly object... it's already loaded.

Am I missing something?

On Tue, Aug 10, 2010 at 4:49 AM, Charles Strahan 
<charles.c.strahan@gmail.com<mailto:charles.c.strahan@gmail.com>> wrote:

Those are valid points. Perhaps #load_assembly could accept an assembly 
reference.

Sent from my iPhone


On Aug 7, 2010, at 5:16 PM, Orion Edwards 
<orion.edwards@gmail.com<mailto:orion.edwards@gmail.com>> wrote:
What's the advantage to extending require?

Presumably you're currently using the .NET Assembly.Load or 
Assembly.LoadFrom methods to do this? (And if you're compiling code in 
memory, you'll certainly be making heavy use of the .NET reflection 
API's already anyway)

Require is a standard part of core ruby, and is meant to take paths.
While it's obvious to overload it to accept paths to dll's as well as rb 
files, overloading it to take non-path things (such as .NET assembly 
objects) seems like it's diverging a bit too far away from it's normal 
(ie: MRI ruby) use, and more into the realms of specific .NET 
extensions...


On 7/08/2010, at 10:08 AM, Charles Strahan wrote:
What would you all think of having the ability to require a given 
Assembly?  I think this could be useful when compiling code in memory, 
in which case there isn't a path to give Kernel.require.

If this is something we could all use, I'll open a ticket for it.

-Charles
_______________________________________________
Ironruby-core mailing list
Ironruby-core@rubyforge.org<mailto:Ironruby-core@rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core

_______________________________________________
Ironruby-core mailing list
Ironruby-core@rubyforge.org<mailto:Ironruby-core@rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core@rubyforge.org<mailto:Ironruby-core@rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
Posted by Charles Strahan (charles-strahan)
on 2010-08-10 22:05
(Received via mailing list)
I'll send you pull request on GitHub, if that will work.

-Charles

On Tue, Aug 10, 2010 at 1:32 PM, Tomas Matousek <
Posted by Charles Strahan (charles-strahan)
on 2010-08-10 22:14
(Received via mailing list)
Oh, I almost forgot; thanks for being so awesome, Tomas :).  Ruby is an
absolute joy to program in, and having IronRuby means I don't have to 
choose
between .NET and Ruby - I get the best of both worlds.  None of that 
would
have been possible without your contributions and dedication to the 
project.
In spite of Microsoft's stance on the future of IronRuby, I hope we can
carry it forward as a stable, reliable implementation.

Thanks,
-Charles


On Tue, Aug 10, 2010 at 1:32 PM, Tomas Matousek <
Posted by Orion Edwards (Guest)
on 2010-08-11 00:32
(Received via mailing list)
Ahh, so you're really after something that "brings in" an already loaded
assembly into IronRuby. Makes perfect sense now.

And thanks again to Tomas :-)

On Wed, Aug 11, 2010 at 7:54 AM, Charles Strahan <
Posted by Charles Strahan (charles-strahan)
on 2010-08-11 00:58
(Received via mailing list)
Yep!  I could have sworn my initial proposition had "an instance of type
Assembly" somewhere in there.  Not the clearest communication on my 
part.

-Charles
Please log in before posting. Registration is free and takes only a minute.
Existing account (Switch to SSL-encrypted connection)
NEW: Do you have a Google/GoogleMail or Yahoo account? No registration required!
Log in with Google account | Log in with Yahoo account
No account? Register here.