Feature #12737: Module#defined_refinements

• Status: Closed
• Assignee: shugo (Shugo Maeda)
• Target version: -

[shugo (Shugo Maeda)]

How about to provide Module#defined_refinements, which returns the refinements defined in the receiver as a Hash, as follows:

module M
  refine String do
    $M_String = self
  end

  refine Integer do
    $M_Integer = self
  end
end

p M.defined_refinements #=> {String => $M_String, Integer => $M_Integer}

By Module#defined_refinements, you can activate refinements globally:

for klass, refinement in M.defined_refinements
  klass.prepend(refinement)
end

[shugo (Shugo Maeda)]

• Related to Feature #9704: Refinements as files instead of modules added

[shugo (Shugo Maeda)]

• Status changed from Open to Assigned

Matz, can I add Module#defined_refinements?

[Eregon (Benoit Daloze)]

• Related to Feature #14332: Module.used_refinements to list refinement modules added

[Eregon (Benoit Daloze)]

Should the code in the description be p M.defined_refinements?

I'm not sure to understand the use case, isn't using M doing the same as that for?

[shugo (Shugo Maeda)]

Eregon (Benoit Daloze) wrote in #note-4:

Should the code in the description be p M.defined_refinements?

Yes.

I'm not sure to understand the use case, isn't using M doing the same as that for?

Forget the following example. It was not a good idea.

for klass, refinement in Module.defined_refinements
  klass.prepend(refinement)
end

Module#defined_refinements is a reflection API for debugging purposes.
You can get a similar result of Module.used_refinements using Module.use_modules and Module#defined_refinements except that Module.used_refinements only returns refinements defined at the time when modules are used.

[Eregon (Benoit Daloze)]

Ah, so it's to list the refinements (instance of Refinement) under a "namespace module" like M, without needing using.
I'm unsure of use cases besides debugging, but I think it's useful to add.

[mame (Yusuke Endoh)]

• Description updated (diff)

[mame (Yusuke Endoh)]

• Description updated (diff)

[shugo (Shugo Maeda)]

Considerations raised by Matz at the developers meeting on 2021-11-18:

1. Is the name defined_refinements appropriate?

   other proposals:

   • configured_refinements (by tenderlove)
   • refinements
     • consistent with Module#constants
   • contained_refinements

2. Should the return value be an Array instead of a Hash?

   pros:

   • consistent with Module.used_refinements

   cons:

   • A new API like Refinement#refined_class (or target_class) is needed to know the refined class.
   • M.defined_refinements.find { |r| r.refined_class == Integer } is longer than M.defined_refinements[Integer].

[Eregon (Benoit Daloze)]

Module#refinements seems nice and straightforward.

I think Refinement#refined_class is useful in any case, +1 to add that.

I slightly prefer the array variant.
Since this would be mostly used for debugging, there might not be any need to filter in many cases, i.e., the Refinement#inspect output already shows the refined_class's name, so p M.refinements seems typical usage (and the Hash for that case would just be more verbose).

[shugo (Shugo Maeda)]

Eregon (Benoit Daloze) wrote in #note-10:

Module#refinements seems nice and straightforward.

I prefer Module#refinements too.

I slightly prefer the array variant.
Since this would be mostly used for debugging, there might not be any need to filter in many cases, i.e., the Refinement#inspect output already shows the refined_class's name, so p M.refinements seems typical usage (and the Hash for that case would just be more verbose).

The array variant is OK for me if Refinement#refined_class will be introduced.

Another use case is testing of Refinements themselves:

m = Module.new {
  refine Integer do
    ....
  end

  refine String do
    ...
  end
}
refinements = m.refinements
assert_something ..., refinements[Integer]
assert_something ..., refinements[String]

However, I may be the only user, so it's not so important.
If there are more use cases, Module#refinement_get can be added in the future.

[matz (Yukihiro Matsumoto)]

OK, accepted. After 3.1, you can introduce:

• Module#refinements
• Refinment#refined_class

Matz.

[shugo (Shugo Maeda)]

• Assignee set to shugo (Shugo Maeda)

[shugo (Shugo Maeda)]

• Status changed from Assigned to Closed

Applied in changeset git|54198c7b97d3d353f7ac233e0360034b6e7b6cb6.

---

Add Module#refinements and Refinement#refined_class [Feature #12737]

[Eregon (Benoit Daloze)]

Refinement#refined_class is a bit strange given it can return a module.
How about adding Refinement#refined_module as an alias for clarity?

[shugo (Shugo Maeda)]

Eregon (Benoit Daloze) wrote in #note-15:

Refinement#refined_class is a bit strange given it can return a module.
How about adding Refinement#refined_module as an alias for clarity?

I'm for it, but it may be better to create another issue.

[Eregon (Benoit Daloze)]

• Related to Feature #19714: Add Refinement#refined_module added