NameError when using user-defined classes as parameter types due to incorrect evaluation binding

[obsidiannnn]

Description

Using user-defined classes as type annotations can raise a NameError due to incorrect constant resolution during evaluation.

Reproduction

class PaymentMethod; end

class Order
  include LowType

  def process(method: PaymentMethod)
    "Processing via #{method.class}"
  end
end

Order.new.process(method: PaymentMethod.new)

Actual Behavior

Raises:

NameError: Unknown type 'PaymentMethod'

Expected Behavior

"Processing via PaymentMethod"

Root Cause

In Evaluator#instance_evaluate, expressions are evaluated using:

eval(proxy.value, binding, ...)

The binding belongs to Low::Evaluator, not the class that includes LowType. As a result, user-defined constants are not visible during evaluation, leading to NameError.

There is also an existing TODO in the code highlighting this:

Evaluate in the binding of the class that included LowType if not a type managed by LowType.

Proposed Direction

Possible approaches to resolve this:

• Pass the including class context into the evaluator
• Resolve constants using const_get within the correct namespace
• Use class_eval on the including class to evaluate expressions in the right scope

Impact

• Breaks support for user-defined types
• Fails for namespaced constants (e.g., MyModule::MyClass)
• Likely affects return type evaluation as well (same evaluation path)

[maedi]

Pass the including class context into the evaluator

I like the sound of this, what's the best way to do this? Could/should we create a method on the including/caller class first like:

def lowtype_get_binding
  binding
end

Then call that from the Evaluator on class load to get the including classes binding... will that actually work?

Breaks support for user-defined types
Fails for namespaced constants (e.g., MyModule::MyClass)

I think these should still work?

[obsidiannnn]

Hey @maedi , thanks for the quick response!
On the binding approach , yes, defining lowtype_get_binding on the including class and calling it from the Evaluator during class load should work. The key is capturing the binding at include time so the constant lookup happens in the right scope.
I'll explore this and test it out.
On the impact you're right to question that. I'll verify both cases (user-defined types and namespaced constants like MyModule::MyClass) against the current code and update the issue if my initial assessment was off.
Will get back with findings soon!

[obsidiannnn]

Hey @maedi
did some digging on the binding approach. The lowtype_get_binding method idea runs into a chicken-and-egg problem , you'd need the class binding to define the method that gives you the binding in the first place.

I tested an alternative using TracePoint :end ... it fires once the class body finishes loading, and at that point trace.self gives the including class, so user-defined constants like PaymentMethod are visible and resolvable via const_get. Tried it out and it's working in my prototype , specs pass with this approach.

So the flow is:

• TracePoint :end captures the including class after the class body loads
• Constants are resolved via const_get in the correct scope
• No need to add any method to the including class

I already have a working implementation on prototype/shim-rewrite
happy to open a PR from there if this direction looks good to you!