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-boun...@rubyforge.org 
[mailto:ironruby-core-boun...@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.edwa...@gmail.com<mailto:orion.edwa...@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.stra...@gmail.com<mailto:charles.c.stra...@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.edwa...@gmail.com<mailto:orion.edwa...@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


_______________________________________________
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
http://rubyforge.org/mailman/listinfo/ironruby-core

Reply via email to