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.


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.


This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs