Issue #20317 has been updated by tenderlovemaking (Aaron Patterson).
jeremyevans0 (Jeremy Evans) wrote in #note-1:
The current behavior may be what you want if you want
to ensure that new instances of the class have `#initialize` called on them. I suppose
you could switch to making `allocate` private, but that still would allow for
`send(:allocate)`.
If we disallow `.new` if `.allocate` is undefined, should we also disallow `#dup` and
`#clone`, both of which also need to allocate an object?
I think that makes sense. For example if you wanted to ensure a particular instance is a
singleton:
```ruby
class Foo; end
singleton = Foo.new
Foo.singleton_class.undef_method(:allocate)
# now there can only be one instance of `Foo` as new / allocate / dup / clone will raise
```
----------------------------------------
Feature #20317: Removing the `allocate` method should cause `new` to fail
https://bugs.ruby-lang.org/issues/20317#change-107104
* Author: tenderlovemaking (Aaron Patterson)
* Status: Open
----------------------------------------
When you remove the `allocate` method from a class the you can't allocate the class
via the `allocate` method. However, you _can_ allocate the class via the `new` method:
```ruby
class Foo; end
Foo.singleton_class.undef_method(:allocate)
begin
Foo.allocate # doesn't work, of course
rescue NoMethodError
end
begin
Class.instance_method(:allocate).bind_call(Foo) # also doesn't work
rescue TypeError
end
Foo.new # works?
```
I think that when we remove the `allocate` method, the `new` method should also fail as
there is no `allocate` method for `new` to call.
--
https://bugs.ruby-lang.org/