[Ironruby-core] Code Review: Procs5
dinov at exchange.microsoft.com
Thu May 1 12:29:40 EDT 2008
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.
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.
More information about the Ironruby-core