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: [email protected] 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 _______________________________________________ Ironruby-core mailing list [email protected] http://rubyforge.org/mailman/listinfo/ironruby-core
