Sorry, I realized after I posted that my issues are based on some questionable assumptions ...
Given that there isn't yet a mechanism for loading ruby extension dlls, I followed the workaround, used for example by the current socket class implementations, where extension classes are simply added along side the builtin classes defined in IronRuby.Libraries. In the longer term, if non-builtin classes are implemented in separate assemblies then my name clash problem becomes less of an issue. I was also assuming that ClassInitGenerator would be used to automatically generate the module initialization code, but this may not necessarily be the case for non-builtin classes implemented in external assemblies. So my per class initialization hook issue also goes away if developers are simply able to manually implement their own equivalent of LoadModules(). It would be nice, however, to decide what this extention loading mechanism is going to be. Also, is there a simple way to test our C# extension libraries standalone (ie without having to run rbx.exe)? In the case of the openssl library it was easy to write a simple C# test harness as the openssl implementation didn't really use any of the IronRuby infrastructure (apart from simple classes such as MutableString). However, for more sophisticated libraries that, for example make use of dynamic call sites, it is difficult to call the library methods without the appropriate CodeContexts etc. Is there an easy way to create the appropriate contexts etc for use in a simple test harness or is it too difficult to bother attempting? Cheers, Wayne. _______________________________________________ Ironruby-core mailing list [email protected] http://rubyforge.org/mailman/listinfo/ironruby-core
