Ruby Forum IronRuby > Code Review: Procs5

tfpt review /shelveset:Procs5;REDMOND\tomat

Refactors Ruby blocks and procs:
-       The compiled block has now signature (BlockParam, self, 
formal-args) - self argument was added. Previously it was passed thru 
BlockParam.Proc in a very hacky way.
-       Removed hacks from dynamic actions on blocks and methods created 
by define_method. Improved rules generated for these actions.
-       RubyBlockInfo no longer inherits from RubyMemberInfo. There is 
no reason to do so, blocks are not directly stored in method tables and 
cannot be invoked via InvokeMemberAction.

Adds YieldAction - a custom Ruby action for yielding to a block that 
allows to pass BlockParam and self.
Implements module_eval/class_eval - both Proc and string versions.
Implements eval that takes Proc as a binding.
Adds module_eval and proc related unit tests.

Tomas

I'm assuming proc's are 1st class things because their IDO's which 
produce a call rule.  Should the extra public properties (Id, Self, 
LocalScope, etc...) be accessible to Ruby programs?  Or should they be 
internal w/ static accessors somewhere in RubyOps?  Also is there a 
reason you can't use object identity instead of ID equality - it seems 
there'll be a 1<->1 relationship here.

Otherwise looks good.

Yes, they are 1st class. Some of the properties should be accessible, 
some not. There will be more cleanup later, after all operations are 
implemented. Some fields might move among classes (RubyBlockInfo, Proc, 
BlockParam) etc. The id is now 1:1 but might not be in future - some 
blocks could be compatible if they have the same signature shape.

Tomas