Refactor (opportunistic): extract _php_member_receiver() out of walk_calls — readability, not a metric fix

[filipechagas]

Recorded from the coupling-metric review of the open upstream PRs. No action required now — this is a readability improvement to make whenever we are next editing that region, not a defect.

Context

An automated reviewer flagged walk_calls() on upstream PRs 2505 and 2506 as an efferent-coupling regression (14 callees). Audited against the base commit:

	base 07b9143d	PR head
definition	engine.py:4201	engine.py:4616
span	4201-4777 (577 lines)	4616-5349 (734 lines)
distinct project callees	13	14

Our diff inside that span is +163 / −6, and the callee set difference is exactly one symbol (_php_name_text). So the metric flag is a threshold crossing, not a structural change — and the function was already 577 lines before we touched it. walk_calls is a nested function inside _extract_generic (engine.py:2691), the multi-language call-walking recursion.

The improvement worth making

engine.py:4808-4847 on the PR head — the ~40-line block deriving member_receiver / php_inline_new_type / php_inline_new_qualified from a member_call_expression — is a pure function of (node, source). It is dense tree-sitter node-shape trivia: variable_name vs member_access_expression vs parenthesized_expression, the unfielded object_creation_expression scan, the anonymous-class edge case, and the _PHP_NON_CONCRETE_TYPE_NAMES refusal.

Extracting it to module scope alongside the other _php_* helpers:

def _php_member_receiver(node, source: bytes) -> tuple[str | None, str | None, str | None]:
    """(receiver, inline_new_type, inline_new_qualified) for a member_call_expression."""

• drops walk_calls from 734 to roughly 695 lines
• makes that logic directly unit-testable, where today it is only reachable through a full extraction run

What it does NOT do

It does not clear the coupling flag. _php_name_text is called exactly once in the whole walk_calls span (head line 4839) — inside that very block — while _read_text and next are used elsewhere and would stay. So the extraction swaps _php_name_text for _php_member_receiver: still 14 callees. If the goal were turning the gate green, this is not the change that does it.

Recommendation

Do not open a PR solely for this, and do not amend 2505/2506 for it — they are open and unreviewed upstream, and rewriting them for a metric that would not go green anyway is churn. Pick it up when we next have reason to edit that region, and land it fork-first as usual.

[filipechagas]

Triage decision (2026-08-07): valid, accepted as a rider — never standalone

The issue is fully specified (exact block, proposed signature, measured non-effect on the coupling metric) and its own recommendation is right: no standalone PR, no amending the open upstream PRs. Relabeling ready-for-agent with an explicit activation condition rather than leaving it in the triage queue:

• Do this only as a rider on the next slice that edits the walk_calls region of graphify/extractors/engine.py — most likely PHP: relative-scope calls (parent::/self::/static::) resolve to nothing — needs a base-class-aware resolution pass (#39 follow-up) #58 (its fix carries the enclosing class onto the raw call, which is rc_entry construction inside that very span). Whoever implements PHP: relative-scope calls (parent::/self::/static::) resolve to nothing — needs a base-class-aware resolution pass (#39 follow-up) #58 should fold this extraction into the same slice.
• Scope stays exactly as written: pure mechanical extraction of the member-receiver derivation to a module-scope _php_member_receiver(node, source) beside the other _php_* helpers, plus direct unit tests for the node-shape trivia (anonymous-class edge case, unfielded object_creation_expression scan, _PHP_NON_CONCRETE_TYPE_NAMES refusal). Behavior-identical by construction; the existing suite plus the new unit tests are the parity evidence.
• Non-goal remains on record: this does not and cannot clear the automated coupling flag (callee swap, not reduction) — do not sell it as that in the commit message.

If the next engine.py-touching cycle skips it, it stays open and rides the one after; it should never generate its own PR.