Ironruby core - Aug 2010 - Should Kernel.require accept Assembly instances?

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20100806/409b18f3/attachment.html>

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

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

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 at 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 at
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 at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>>
>>
>> _______________________________________________
>> Ironruby-core mailing list
>> Ironruby-core at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>
> _______________________________________________
> 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/20100810/4ec5684f/attachment.html>

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.edwards at
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 at 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 at
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 at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>>>
>>>
>>> _______________________________________________
>>> Ironruby-core mailing list
>>> Ironruby-core at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>>
>> _______________________________________________
>> Ironruby-core mailing list
>> Ironruby-core at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>
>
>
> _______________________________________________
> 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/20100810/2864eb23/attachment.html>

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 at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Charles Strahan
Sent: Tuesday, August 10, 2010 11:04 AM
To: ironruby-core at 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 at
gmail.com<mailto:orion.edwards at 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 at
gmail.com<mailto:charles.c.strahan at 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 at
gmail.com<mailto:orion.edwards at 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 at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core

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


_______________________________________________
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/20100810/9f8e34c5/attachment-0001.html>

I''ll send you pull request on GitHub, if that will work.

-Charles

On Tue, Aug 10, 2010 at 1:32 PM, Tomas Matousek <
Tomas.Matousek at 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-bounces at rubyforge.org [mailto:
> ironruby-core-bounces at rubyforge.org] *On Behalf Of *Charles Strahan
> *Sent:* Tuesday, August 10, 2010 11:04 AM
> *To:* ironruby-core at 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.edwards at
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 at 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 at
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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>
>
> _______________________________________________
> 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/20100810/527bdf2d/attachment.html>

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.Matousek at 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-bounces at rubyforge.org [mailto:
> ironruby-core-bounces at rubyforge.org] *On Behalf Of *Charles Strahan
> *Sent:* Tuesday, August 10, 2010 11:04 AM
> *To:* ironruby-core at 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.edwards at
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 at 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 at
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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>
>
> _______________________________________________
> 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/20100810/5e815e20/attachment-0001.html>

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.strahan at 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.Matousek at 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-bounces at rubyforge.org [mailto:
>> ironruby-core-bounces at rubyforge.org] *On Behalf Of *Charles Strahan
>> *Sent:* Tuesday, August 10, 2010 11:04 AM
>> *To:* ironruby-core at 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.edwards at
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 at 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 at
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 at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>
>>
>> _______________________________________________
>> Ironruby-core mailing list
>> Ironruby-core at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>
>> _______________________________________________
>> Ironruby-core mailing list
>> Ironruby-core at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>
>>
>>
>>
>> _______________________________________________
>> Ironruby-core mailing list
>> Ironruby-core at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>
>>
>>
>> _______________________________________________
>> Ironruby-core mailing list
>> Ironruby-core at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>
>>
>
> _______________________________________________
> 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/20100811/3d17ae72/attachment.html>

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.edwards at
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.strahan at 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.Matousek at 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-bounces at rubyforge.org [mailto:
>>> ironruby-core-bounces at rubyforge.org] *On Behalf Of *Charles
Strahan
>>> *Sent:* Tuesday, August 10, 2010 11:04 AM
>>> *To:* ironruby-core at 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.edwards at
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 at 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 at
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 at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>>
>>>
>>> _______________________________________________
>>> Ironruby-core mailing list
>>> Ironruby-core at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>>
>>> _______________________________________________
>>> Ironruby-core mailing list
>>> Ironruby-core at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Ironruby-core mailing list
>>> Ironruby-core at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>>
>>>
>>>
>>> _______________________________________________
>>> Ironruby-core mailing list
>>> Ironruby-core at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>>
>>>
>>
>> _______________________________________________
>> Ironruby-core mailing list
>> Ironruby-core at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>
>>
>
> _______________________________________________
> 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/20100810/892c7678/attachment-0001.html>