On 9/14/07, Marcin Mielżyński <[EMAIL PROTECTED]> wrote: > > It turns out that in trunk classes are being > put into parents using setInstanceVariable(...) but modules are being > put using setConstant(...), whereas MRI consistently uses > rb_const_set/rb_const_get_at/rb_const_defined_at.
In trunk, #setInstanceVariable is used in a lot of places to avoid validation and other behaviors associated with other setXxx methods. This sort of works, since all ivars/cvars/constants/internal variables are stored in the same hash table. But setInstanceVariable does some checks, too, which turn out to be wrong in many cases where it's called to set something other than an instance variable. RubyClass#newSubClass uses setInstanceVariable to avoid a warning message that setConstant would issue if the subclass were already defined. (There's a potential issue there, as setConstant does more than just set the value, it also sets the base name in the class/module. I've flagged this in my branch.) In the new variables code (see bdortch/attrs) this is all handled differently, and setInstanceVariables is used *only* to set ivars (with assertions enabled, an exception will be raised if a non-ivar name is passed to it). Also, in code I haven't yet committed, constants are actually stored in a separate hash table with a different entry type. are set/get/Constant methods going to change drastically too after > your work..? Yes, but you can leave the code as it is if you like, I'll take care of it when I merge your changes in trunk to my attrs branch. -Bill
