[Ironruby-core] Code Review: Procs5

[Dino Viehland]

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.

-----Original Message-----
From: Tomas Matousek
Sent: Tuesday, April 29, 2008 8:16 PM
To: Rowan Code Reviewers; IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org
Subject: 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