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
On Tue, Aug 10, 2010 at 5:22 PM, Orion Edwards <orion.edwa...@gmail.com>wrote:
> 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 <
> charles.c.stra...@gmail.com> wrote:
>
>> 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 <
>> tomas.matou...@microsoft.com> wrote:
>>
>>> 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 == '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>
>>> 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> 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>
>>> 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
>>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>>
>>>
>>> _______________________________________________
>>> Ironruby-core mailing list
>>> 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
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Ironruby-core mailing list
>>> 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
>>>
>>>
>>
>> _______________________________________________
>> Ironruby-core mailing list
>> 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
>
>
_______________________________________________
Ironruby-core mailing list
Ironruby-core@rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core
