Feature #8046

allow Object#extend to take a block

Added by Matthew Kerwin about 1 year ago. Updated about 1 year ago.

[ruby-core:53211]
Status:Open
Priority:Normal
Assignee:-
Category:-
Target version:next minor

Description

=begin
In #8038 david_macmahon proposed:

How about allowing Object#extend to take a block that would be executed with the context such that methods defined therein would become singleton methods of the object receiving #extend?

For example:
foo = Object.new
foo.extend do
def bar
# ...
end
def baz
# ...
end
end
=end

History

#1 Updated by Charlie Somerville about 1 year ago

=begin
There are two ways to do this - make the extend block execute in the context of the receiver's singleton class, or make it execute in the context of a new module to be mixed in to the receiver's singleton class.

For example:

def extend(&bk)
  singleton_class.class_eval(&bk)
end

or

def extend(&bk)
  singleton_class.send(:include, Module.new(&bk))
end

Which should it be?
=end

#2 Updated by Matthew Kerwin about 1 year ago

charliesome (Charlie Somerville) wrote:

There are two ways to do this - make the extend block execute in the
context of the receiver's singleton class, or make it execute in the
context of a new module to be mixed in to the receiver's singleton class.
...
Which should it be?

I'd think more like the former, as that doesn't inject a new anonymous Module into the singleton_class's #ancestors.

Does classeval do anything dramatically different from moduleeval (i.e. is the block handled differently in either case)?

#3 Updated by David MacMahon about 1 year ago

On Mar 7, 2013, at 6:53 PM, charliesome (Charlie Somerville) wrote:

There are two ways to do this

def extend(&bk)
singletonclass.classeval(&bk)
end

or

def extend(&bk)
singleton_class.send(:include, Module.new(&bk))
end

At the risk of being overly pedantic, since we're talking about Object#extend, I think it would be more like:

def extend(*modules, &bk)
# extend singletonclass with modules, if any
singleton
class.class_eval(&bk) if bk
end

or

def extend(module=nil, &bk)
# extend singletonclass with modules, if any
singleton
class.send(:include, Module.new(&bk)) if bk
end

Which raises another question: what would be the order of extending if #extend is passed one or more modules and given a block? IOW, should the passed in module(s) be included first thereby giving the block the opportunity to override them or vice versa (or should this be explicitly disallowed)? I guess I'd favor the first way (include module(s) first, then block can override).

On the original question I tend to agree with @phluid61 that it would be preferable to avoid inserting an anonymous Module in the singleton_class's ancestors. Would having the anonymous module provide any advantage over not having it?

Thanks,
Dave

P.S. Why "singletonclass.send(:include, Module.new(&bk))" instead of just "singletonclass.include(Module.new(&bk))"? Are these somehow not equivalent?

#4 Updated by Matthew Kerwin about 1 year ago

david_macmahon (David MacMahon) wrote:

Which raises another question: what would be the order of extending if
#extend is passed one or more modules and given a block? IOW, should
the passed in module(s) be included first thereby giving the block the
opportunity to override them or vice versa (or should this be explicitly
disallowed)? I guess I'd favor the first way (include module(s) first,
then block can override).

That's the order Facets uses: https://github.com/rubyworks/facets/blob/master/lib/core/facets/kernel/extend.rb

On the original question I tend to agree with @phluid61 that it would be
preferable to avoid inserting an anonymous Module in the
singleton_class's ancestors. Would having the anonymous module provide
any advantage over not having it?

My reasoning against was that on calling it a second time, there would be a second anonymous module, and so on.

P.S. Why "singletonclass.send(:include, Module.new(&bk))" instead of
just "singleton
class.include(Module.new(&bk))"? Are these somehow not
equivalent?

#include is private, so can't be called directly from outside the singleton_class object.

#5 Updated by Nobuyoshi Nakada about 1 year ago

Without a module, it'd not be #extend but #singletonclasseval.

Also available in: Atom PDF