Expose class boundaries and track private keyword location in class_proxy.rb

[nikitakar9862]

Problem

---

Currently, in class_proxy.rb, ClassProxy does not provide any access to the start_line and end_line of the class definition. Although the node is stored but its location information (@node.location.start_line and @node.location.end_line) is not exposed.

This makes it difficult for visitors like method_call_visitor.rb to determine whether a private call appears inside the class body, especially with nested classes.

For example:

class Hello
  private  # visitor sees this, but it doesn't know the class Hello boundaries

  def greet
   puts "hello"
  end
end

Suggested Solution

---

To solve this issue, we need to update both ClassProxy and the visitor logic.

1. Update ClassProxy in class_proxy.rb by adding methods to expose the node's location data:

def start_line
  @node.location.start_line
end

def end_line
  @node.location.end_line
end

2. Update Visitor Logic in method_call_visitor.rb:

class_proxy.method_calls ||= []
class_proxy.method_calls << node

return unless node.name == :private 

node_start_line = node.location.start_line

# Provide safety checks to ensure ClassProxy supports boundaries
can_check_bounds = class_proxy.respond_to?(:start_line) && class_proxy.respond_to?(:end_line)
can_assign = class_proxy.respond_to?(:private_start_line=)

return unless can_check_bounds && can_assign

# Only track 'private' if it's actually inside the class body
if node_start_line > class_proxy.start_line && node_start_line < class_proxy.end_line
  class_proxy.private_start_line = node_start_line
end

This will ensure that the method visibility is tracked accurately and doesn't "leak" between nested classes or separate class definitions in the same file. @maedi brother, I'm planning to work on this issue. Before I start, I would love to get some feedback from you.

[nikitakar9862]

Update on Issue #4

I am encountering a NoMethodError while testing the integration with Low_Type. The MethodCallVisitor (line 19) attempts to call end_line on a ClassProxy instance to determine the method visibility, but these methods are missing in the class_proxy.rb .

Error Trace:

[maedi]

@nikitakar9862, Yes RE last issue, just give me a few hours and I will be releasing new versions of lowtype/lowkey that work together

[nikitakar9862]

@maedi brother, I have fixed the bug in both LowKey and Low_Type. Would it be okay if I raise a PR for you to review it

[maedi]

The missing end_line method bug has been fixed. Please rebase PR if need

[maedi]

ClassProxy does not provide any access to the start_line and end_line of the class definition.

It does via its parent:
https://github.com/low-rb/lowkey/blob/main/lib/proxies/module_proxy.rb

...which via its parent:
https://github.com/low-rb/lowkey/blob/main/lib/interfaces/proxy.rb

...delegates the start_line and end_line methods to the proxy's @source:
https://github.com/low-rb/lowkey/blob/main/lib/models/source.rb

Sorry, this particular abstraction is very layered and fragmented and confusing. It is probably the cleanest way to do what we need to do though, which is make every Proxy be able to share the same Source.

This makes it difficult for visitors like method_call_visitor.rb to determine whether a private call appears inside the class body, especially with nested classes

Yes, this existing code could very well be wrong:

def visit(node)
  namespace = namespace(node:, parent_map:)
  module_proxy = file_proxy[namespace]

  module_proxy.method_calls << node
  upsert_dependency(node:, namespace:)

  return unless node.name == :private && node.respond_to?(:start_line) && module_proxy.start_line && module_proxy.end_line
  return unless node.start_line > module_proxy.start_line && node.start_line < module_proxy.end_line

  module_proxy.private_start_line = node.start_line
end

If you re-read it knowing that module_proxy also represents a ClassProxy (well I think it does), does the code actually seem to work? If there's any doubt, let's write a test that proves that this is not working. I only refactored the parser to track modules as well as classes a day or so ago, so apologies

[nikitakar9862]

Hi @maedi brother, hope you are well. Sorry for the late reply, I was busy with my college lab practical exams.

Update on the private visibility issue: I ran a test on nested classes and it passed. It looks like the visitor logic is scoping correctly and there is no leakage to the parent class.

---

The test that I wrote:

Is there anything else you would like me to test?

[maedi]

A test like this will be a good addition, but I'm not sure if the premise makes sense; the parent class wouldn't inherit a method from the child class, just as a default Ruby behaviour that wouldn't happen. Was LowType doing something weird to make that possibly happen that you saw?

A related test could be around this concept:

Subclass Access: Unlike many other languages, private methods in Ruby are inherited and can be called by subclasses.

Also instead of require 'tempfile, which I'm not familiar with (though maybe I should be?), let's just create a fixture file.