A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://bugs.ruby-lang.org/issues/12737 below:

Feature #12737: Module#defined_refinements - Ruby

Matz, can I add Module#defined_refinements?

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?

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.

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.

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

  1. Is the name defined_refinements appropriate?

    other proposals:

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

    pros:

    cons:

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).

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.

OK, accepted. After 3.1, you can introduce:

Matz.

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

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.


RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.3