Feature #3773: Module#parent

• Status: Rejected
• Assignee: matz (Yukihiro Matsumoto)
• Target version: -

[trans (Thomas Sawyer)]

=begin
Not sure "parent" is the best name, it does seem like this functionality should be provided somehow by Ruby itself.

class Module
# Returns the name of the module containing this one.
#
# M::N.parent_name # => "M"
def parent_name
unless defined? @parent_name
@parent_name = name =~ /::[^:]+\Z/ ? $`.freeze : nil
end
@parent_name
end

 # Returns the module which contains this one according to its name.
 #
 #   module M
 #     module N
 #     end
 #   end
 #   X = M::N
 #
 #   M::N.parent # => M
 #   X.parent    # => M
 #
 # The parent of top-level and anonymous modules is Object.
 #
 #   M.parent          # => Object
 #   Module.new.parent # => Object
 #
 def parent
   parent_name ? constant(parent_name) : Object
 end

 # Returns all the parents of this module according to its name, ordered from
 # nested outwards. The receiver is not contained within the result.
 #
 #   module M
 #     module N
 #     end
 #   end
 #   X = M::N
 #
 #   M.parents    # => [Object]
 #   M::N.parents # => [M, Object]
 #   X.parents    # => [M, Object]
 #
 def parents
   parents = []
   if parent_name
     parts = parent_name.split('::')
     until parts.empty?
       parents << constant(parts * '::')
       parts.pop
     end
   end
   parents << Object unless parents.include? Object
   parents
 end

end
=end

[matz (Yukihiro Matsumoto)]

=begin
Hi,

In message "Re: [ruby-core:31969] [Ruby 1.9-Feature#3773][Open] Module#parent"
on Wed, 1 Sep 2010 00:24:25 +0900, Thomas Sawyer [e-mail] writes:

|Not sure "parent" is the best name, it does seem like this functionality should be provided somehow by Ruby itself.

Objection.

(a) I don't think "parent" is a proper name for the feature.
(b) returning Object for anonymous module is weird behavior.

						matz.

=end

[trans (Thomas Sawyer)]

=begin
I agree and I have another objection to add.

(c) A constant name is just a reference to an object.

That is to say, like any variable name, the object does not know it has been assigned it. If someone did C::D = A::B, then what would C::D.parent be?

However my objection also argues against having Module#name at all. So perhaps for modules their is a necessary exception? Actually, this is partly why I bring up this suggested feature --to better understand why modules even know their names in the first place.

As for objection (a) I have seen other suggestions: enclosing_module, enclosure, container, namespace, enclosing_namespace, modspace, etc.

For objection (c), that's a good point. nil would be a better return value in that case.

						trans.

=end

[trans (Thomas Sawyer)]

=begin
"For objection (c), that's a good point. nil would be a better return value in that case."

I meant, "objection (b)".

matz, do you have a preference for a name?
=end

[matz (Yukihiro Matsumoto)]

=begin
Hi,

In message "Re: [ruby-core:32038] [Ruby 1.9-Feature#3773] Module#parent"
on Fri, 3 Sep 2010 20:03:34 +0900, Thomas Sawyer [e-mail] writes:

|Issue #3773 has been updated by Thomas Sawyer.
|
|
|"For objection (c), that's a good point. nil would be a better return value in that case."
|
|I meant, "objection (b)".
|
|matz, do you have a preference for a name?

As pointed by objection (c), a constant name is just a reference to
a module/class object. For example, the following code creates two
references to the A::B module:

module A
module B
end
end
C = A::B

Although a module records the first reference name, just for
convenience, having a method to retrieve "a parent of the primary
reference" makes me feel bit weird.

If you show me a real use-case, I might feel different.

						matz.

=end

[trans (Thomas Sawyer)]

=begin
The use cases that I am aware of are from Rails:

• http://github.com/rails/rails/blob/master/activesupport/lib/active_support/dependencies.rb#L496
• http://github.com/rails/rails/blob/master/activerecord/lib/active_record/associations.rb#L1827

=end

[matz (Yukihiro Matsumoto)]

=begin
Hi,

In message "Re: [ruby-core:32103] [Ruby 1.9-Feature#3773] Module#parent"
on Tue, 7 Sep 2010 23:19:43 +0900, Thomas Sawyer [e-mail] writes:

|The use cases that I am aware of are from Rails:
|
|* http://github.com/rails/rails/blob/master/activesupport/lib/active_support/dependencies.rb#L496
|* http://github.com/rails/rails/blob/master/activerecord/lib/active_record/associations.rb#L1827

Well, the former implicitly assumes specific structure of loading
libraries, which is not supported by Ruby itself. The latter,
..well.. has proven how Ruby+activesupport looks differently from plain
Ruby ;-)

In any way, when ActiveSupport defines #parent, I don't see any reason
to add it to the core. Besides that #parent can be easily confused
with #superclass.

						matz.

=end

[trans (Thomas Sawyer)]

=begin
Mainly I suggest it be added to core on the basis that 1) since we already have Module#name we might as well have this too, and 2) it is very inefficient and non-robust to code in pure Ruby.

And yes, I agree that #parent is the wrong name. What would you call it? I want to know b/c, even if you do not add it to core, I want to add it to Ruby Facets, but I am not sure what to call it myself.
=end

[trans (Thomas Sawyer)]

=begin
Had a thought today about this. How about calling it home? That semantically makes sense with the fact that it is actually just a reference and therefore could be assigned to other names and thus other "enclosures", but still it would have only one "home" --the original place of definition.
=end

[nahi (Hiroshi Nakamura)]

• Description updated (diff)
• Status changed from Open to Rejected
• Assignee set to matz (Yukihiro Matsumoto)

I mark this Rejected since Matz rejected it. Sorry for not respecting your extra concern. It would be good to file this as a new issue.

[trans (Thomas Sawyer)]

I will eventually try again. I don't really understand having #name, but not being able to get the actual constant named by #name.