Skip to content
  • John Hawthorn's avatar
    733500e9
    Lazily create singletons on instance_{exec,eval} (#5146) · 733500e9
    John Hawthorn authored
    
    
    * Lazily create singletons on instance_{exec,eval}
    
    Previously when instance_exec or instance_eval was called on an object,
    that object would be given a singleton class so that method
    definitions inside the block would be added to the object rather than
    its class.
    
    This commit aims to improve performance by delaying the creation of the
    singleton class unless/until one is needed for method definition. Most
    of the time instance_eval is used without any method definition.
    
    This was implemented by adding a flag to the cref indicating that it
    represents a singleton of the object rather than a class itself. In this
    case CREF_CLASS returns the object's existing class, but in cases that
    we are defining a method (either via definemethod or
    VM_SPECIAL_OBJECT_CBASE which is used for undef and alias).
    
    This also happens to fix what I believe is a bug. Previously
    instance_eval behaved differently with regards to constant access for
    true/false/nil than for all other objects. I don't think this was
    intentional.
    
        String::Foo = "foo"
        "".instance_eval("Foo")   # => "foo"
        Integer::Foo = "foo"
        123.instance_eval("Foo")  # => "foo"
        TrueClass::Foo = "foo"
        true.instance_eval("Foo") # NameError: uninitialized constant Foo
    
    This also slightly changes the error message when trying to define a method
    through instance_eval on an object which can't have a singleton class.
    
    Before:
    
        $ ruby -e '123.instance_eval { def foo; end }'
        -e:1:in `block in <main>': no class/module to add method (TypeError)
    
    After:
    
        $ ./ruby -e '123.instance_eval { def foo; end }'
        -e:1:in `block in <main>': can't define singleton (TypeError)
    
    IMO this error is a small improvement on the original and better matches
    the (both old and new) message when definging a method using `def self.`
    
        $ ruby -e '123.instance_eval{ def self.foo; end }'
        -e:1:in `block in <main>': can't define singleton (TypeError)
    
    Co-authored-by: default avatarMatthew Draper <matthew@trebex.net>
    
    * Remove "under" argument from yield_under
    
    * Move CREF_SINGLETON_SET into vm_cref_new
    
    * Simplify vm_get_const_base
    
    * Fix leaf VM_SPECIAL_OBJECT_CONST_BASE
    
    Co-authored-by: default avatarMatthew Draper <matthew@trebex.net>
    733500e9
    Lazily create singletons on instance_{exec,eval} (#5146)
    John Hawthorn authored
    
    
    * Lazily create singletons on instance_{exec,eval}
    
    Previously when instance_exec or instance_eval was called on an object,
    that object would be given a singleton class so that method
    definitions inside the block would be added to the object rather than
    its class.
    
    This commit aims to improve performance by delaying the creation of the
    singleton class unless/until one is needed for method definition. Most
    of the time instance_eval is used without any method definition.
    
    This was implemented by adding a flag to the cref indicating that it
    represents a singleton of the object rather than a class itself. In this
    case CREF_CLASS returns the object's existing class, but in cases that
    we are defining a method (either via definemethod or
    VM_SPECIAL_OBJECT_CBASE which is used for undef and alias).
    
    This also happens to fix what I believe is a bug. Previously
    instance_eval behaved differently with regards to constant access for
    true/false/nil than for all other objects. I don't think this was
    intentional.
    
        String::Foo = "foo"
        "".instance_eval("Foo")   # => "foo"
        Integer::Foo = "foo"
        123.instance_eval("Foo")  # => "foo"
        TrueClass::Foo = "foo"
        true.instance_eval("Foo") # NameError: uninitialized constant Foo
    
    This also slightly changes the error message when trying to define a method
    through instance_eval on an object which can't have a singleton class.
    
    Before:
    
        $ ruby -e '123.instance_eval { def foo; end }'
        -e:1:in `block in <main>': no class/module to add method (TypeError)
    
    After:
    
        $ ./ruby -e '123.instance_eval { def foo; end }'
        -e:1:in `block in <main>': can't define singleton (TypeError)
    
    IMO this error is a small improvement on the original and better matches
    the (both old and new) message when definging a method using `def self.`
    
        $ ruby -e '123.instance_eval{ def self.foo; end }'
        -e:1:in `block in <main>': can't define singleton (TypeError)
    
    Co-authored-by: default avatarMatthew Draper <matthew@trebex.net>
    
    * Remove "under" argument from yield_under
    
    * Move CREF_SINGLETON_SET into vm_cref_new
    
    * Simplify vm_get_const_base
    
    * Fix leaf VM_SPECIAL_OBJECT_CONST_BASE
    
    Co-authored-by: default avatarMatthew Draper <matthew@trebex.net>
Loading