Feature #5088

Refactor and Document vm_method.c / method.h

Added by Lazaridis Ilias almost 4 years ago. Updated about 3 years ago.

[ruby-core:38444]
Status:Closed
Priority:Normal
Assignee:Koichi Sasada

Description

=begin
(not a "Feature" but a "Task")

Refactoring and documentation of the following files:

  • source:vm_method.c
  • source:method.h
  • 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)

=end

History

#1 Updated by hemant kumar almost 4 years ago

@Ilias,

Please submit any improvement with a patch. It is pointless to open a request without a patch and with due respect - wastes Ruby-Core valuable time.

#2 Updated by Lazaridis Ilias almost 4 years ago

=begin
hemant kumar wrote:

@Ilias,

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)

=end

#3 Updated by Lazaridis Ilias almost 4 years ago

=begin

You can follow the rework on this location:

((URL:https://github.com/lazaridis-com/ruby/tree/refactor_vm_method))

What is the preferred method? Sending refactoring patches one-by-one for commit, or as a one big patch when it's finished?

=end

#4 Updated by Yusuke Endoh over 3 years ago

  • Status changed from Open to Assigned
  • Assignee set to Koichi Sasada

#5 Updated by Koichi Sasada about 3 years ago

  • Status changed from Assigned to Closed

I think we need to discuss about each spec, before implementation (of course, a proposal with an implementation is welcome). Please persuade matz before you try to commit your patch.

Also available in: Atom PDF