From: eregontp@...
Date: 2017-03-27T16:05:34+00:00
Subject: [ruby-core:80393] [Ruby trunk Bug#13358] OpenStruct overriding	allocate

Issue #13358 has been updated by Eregon (Benoit Daloze).


nobu (Nobuyoshi Nakada) wrote:
> Eregon (Benoit Daloze) wrote:
> > But not only, after all it is a public and well-known method (many hits on GitHub code search).
> > Many deserializing libraries will use it,
> 
> Methods of constructed objects will be used more than construction usually.
> 
> > but also various libraries which need to build an instance without passing in state,
> > or use it as a way to replicate `Class#new` without using super like (maybe to use a different initializing method):
> 
> It doesn't need `allocate`, `CACHE[name] || super`.

Yes, nevertheless existing code uses it.
And if sby needed some special method like #initialize_native,
calling #allocate is the most natural way to do it in Ruby.

> > The performance hit on `respond_to?` is not significant, it's just an extra `NIL_P`.
> 
> And a branch.

Which is insignificant compared to the rest of the logic in #respond_to?.

> > On the other hand, the one on `allocate` is, and affects every caller of `OpenStruct.allocate`.
> 
> Why do you think the performance of `allocate` matters?
> Note that it is never used in common, since `Class#new` never calls `allocate` overridden in ruby level.

I think this bug is no reason to make a method 2x slower.
Ruby code might call #allocate for various reasons.

But my main issue with this fix is it only addresses a specific use-case and not the general issue:
#respond_to? should work on any object, even uninitialized and just #allocate-d.
Kernel#respond_to_missing? works on any object, but OpenStruct#respond_to_missing? does not currently.

For instance, Class.instance_method(:allocate).bind(OpenStruct).call.respond_to?(:foo) breaks.
Same for rb_obj_alloc() + rb_obj_respond_to() or Ruby #respond_to?
Note that all of these used to work in Ruby 2.2.

I will commit my patch unless you object.
It is more robust and has no significant downside.

----------------------------------------
Bug #13358: OpenStruct overriding allocate
https://bugs.ruby-lang.org/issues/13358#change-63883

* Author: sitter (Harald Sitter)
* Status: Closed
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: ruby 2.4.0p0 (2016-12-24 revision 57164) [x86_64-linux]
* Backport: 2.2: DONTNEED, 2.3: DONE, 2.4: DONTNEED
----------------------------------------
In https://github.com/ruby/ruby/commit/15960b37e82ba60455c480b1c23e1567255d3e05 OpenStruct gained

~~~ruby
  class << self # :nodoc:
    alias allocate new
  end
~~~

Which is rather severely conflicting with expected behavior as `Class.allocate` is meant to [not call initialize](http://ruby-doc.org/core-2.4.0/Class.html#method-i-allocate). So, in fact, the change made `allocate` of `OpenStruct` do what `allocate` is asserting not to do :-/

For `OpenStruct` itself that isn't that big a deal, for classes inheriting from `OpenStruct` it breaks `allocate` though.

Example:

~~~ruby
require 'ostruct'

class A < OpenStruct
  def initialize(x, y = {})
    super(y)
  end
end

A.allocate
~~~

As `allocate` is alias'd to `new` in `OpenStruct` this will attempt to initialize `A` which will raise an `ArgumentError` because `A` cannot be initialized without arguments.

~~~
$ ruby x.rb
x.rb:4:in `initialize': wrong number of arguments (given 0, expected 1..2) (ArgumentError)
        from x.rb:9:in `new'
        from x.rb:9:in `<main>'
~~~

OpenStruct at the very least should document the fact that its allocate is behaving differently.
Ideally, `OpenStruct` should not alias allocate at all.




-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>