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 thatfor
?
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:
Is the name defined_refinements appropriate?
other proposals:
Should the return value be an Array instead of a Hash?
pros:
cons:
M.defined_refinements.find { |r| r.refined_class == Integer }
is longer than M.defined_refinements[Integer]
.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, sop 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 addingRefinement#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