[Ironruby-core] ClassInitGenerator issues

Tomas Matousek Tomas.Matousek at microsoft.com
Tue Feb 26 17:03:00 EST 2008

I think it is reasonable to add custom initialization method for classes to ClassInitGenerator. However, it is still better (for tooling, reduction of duplicated code etc.) to initialize classes declaratively (using attributes) than imperatively (executing arbitrary code).

The class name clash is a bug that we will fixed. ClassInitGenerator doesn't need to be used by all extensions but will be recommended.

As for testing, the preferred way to test libraries is to write RSpec tests and contribute them to Rubinius. John will write more on specs.


-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Wayne Kelly
Sent: Tuesday, February 26, 2008 12:43 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] ClassInitGenerator issues

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
Ironruby-core at rubyforge.org

More information about the Ironruby-core mailing list