Refactor and Document vm_method.c / method.h
(not a "Feature" but a "Task")
Refactoring and documentation of the following files:
- other indirectly affected files
This will not alter the functionality in any way, but will change only whitespace, structure and naming.
The goals are
* to make the method handling easier to understand.
* to enable more developers to maintain the code
* To simplify processing/implementation of issues: #4893, #5005
* To simplify the completition/extension of the method-handling
* to prepare for a later redesign of vm_method.c (towards "methods are objects")
(patches follow by time, if no objecting is given)
#2 [ruby-core:38448] Updated by lazaridis.com (Lazaridis Ilias) about 6 years ago
hemant kumar wrote:
Please submit any improvement with a patch. It is pointless to open a request without a patch
Mr. Kumar, I don't know who you are, but the rule you state is not existent within this project.
and with due respect - wastes Ruby-Core valuable time.
I guess it distracts the list from the relevant stuff, like making jokes: #5054 ?
As I've possibly not expressed myself clear:
- Task announced, asking for general objections.
- If no objections, I'll continue and provide the patches (which can of course be objected/rejected)
#3 [ruby-core:38494] Updated by lazaridis.com (Lazaridis Ilias) about 6 years ago
You can follow the rework on this location:
What is the preferred method? Sending refactoring patches one-by-one for commit, or as a one big patch when it's finished?