What do you see would be the advantage of something like this as opposed to the current method of loading .NET assemblies? I mean you could use something like OpenSSL.NET (http://openssl-net.sourceforge.net/) today to implement ssl in IronRuby for example
I believe a future goal is to actually support loading unmanaged extensions (this is based strictly on comments in the code, noone's actually said this as far as I know). On Feb 13, 2008 6:58 PM, Wayne Kelly <[EMAIL PROTECTED]> wrote: > > > For Ruby libraries such as sockets, openssl etc (ie not built-in classes or > modules), I assume we will implement/port them using say C# to produce a > managed dll (eg socket.dll). Client programs will then require 'socket', and > IronRuby will load socket.dll rather than socket.so > > I note IronRuby already has the ability to load managed dlls such as > mscorlib - but that appears to simply load the assembly and then presumably > uses .NET reflection to expose the .NET classes as Ruby classes. But for > managed dll such as socket.dll that has been specifically engineered as an > IronRuby extension dll, I image the loading process would be a little > different? CRuby, for example exposes an Init_Foo function which explicitly > calls define_class, define_method etc to explicitly register each of the > Ruby classes implemented by that library (equivalent to what IronRuby does > in LibrariesInitializer.LoadModules). > > Will there be a similar convention used by IronRuby? Possibly in static > class constructors? > > Cheers, Wayne. > _______________________________________________ > Ironruby-core mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/ironruby-core > > -- Michael Letterle [Polymath Programmer] http://michaeldotnet.blogspot.com _______________________________________________ Ironruby-core mailing list [email protected] http://rubyforge.org/mailman/listinfo/ironruby-core
