Feature Description
Description
Currently, classFields completion's fetchClass option supports three modes: "current" (the callee class), "containingClassField:fieldName" (a property on the containing class), and a fixed "classFqn" string. All three resolve the target class from the call site's structure or a static value — none of them can resolve the class from another parameter's literal value passed in the same call.
This makes it impossible to get correct autocomplete for a common pattern: a generic helper function that takes a class FQN as one argument and a property name of that class as another, e.g.:
toSnakeCase(ThemeSettings::class, 'helpScoutSupportBeaconId');
// ^ would like this suggested based on ThemeSettings
Requested feature
A new fetchClass mode, e.g. "parameter:N", that resolves the target class from the literal value of parameter N in the same call — when that parameter is a ::class constant reference (similar to how class-string<T> is resolved by Psalm/PHPStan in a templated context).
Example ide.json usage
{
"complete": "classFields",
"options": {
"fetchClass": "parameter:1",
"fieldsFilter": { "fetch": "own", "modifier": ["public", "protected"] }
},
"condition": [
{ "functionNames": ["toSnakeCase"], "parameters": [2] }
]
}Why this matters
Right now, the only workaround is restructuring the API so the class is the callee rather than an argument (e.g. ThemeSettings::toSnakeCase('...') via a shared trait), which works but forces an API shape change purely to satisfy IDE tooling. A fetchClass: "parameter:N" mode would let generic hydration/mapping/conversion helpers (a very common pattern — DTO mappers, snake_case/camelCase converters, attribute accessors) keep a natural fn($classFqn, $propertyName) signature while still getting correct, class-specific IDE suggestions.
I'd guess this is at minimum a moderate lift, since it likely requires resolving the literal ::class expression passed at each call site (not just a static config value) before the completion provider runs.
Feature Description
Description
Currently,
classFieldscompletion'sfetchClassoption supports three modes:"current"(the callee class),"containingClassField:fieldName"(a property on the containing class), and a fixed"classFqn"string. All three resolve the target class from the call site's structure or a static value — none of them can resolve the class from another parameter's literal value passed in the same call.This makes it impossible to get correct autocomplete for a common pattern: a generic helper function that takes a class FQN as one argument and a property name of that class as another, e.g.:
Requested feature
A new
fetchClassmode, e.g."parameter:N", that resolves the target class from the literal value of parameterNin the same call — when that parameter is a::classconstant reference (similar to howclass-string<T>is resolved by Psalm/PHPStan in a templated context).Example
ide.jsonusage{ "complete": "classFields", "options": { "fetchClass": "parameter:1", "fieldsFilter": { "fetch": "own", "modifier": ["public", "protected"] } }, "condition": [ { "functionNames": ["toSnakeCase"], "parameters": [2] } ] }Why this matters
Right now, the only workaround is restructuring the API so the class is the callee rather than an argument (e.g.
ThemeSettings::toSnakeCase('...')via a shared trait), which works but forces an API shape change purely to satisfy IDE tooling. AfetchClass: "parameter:N"mode would let generic hydration/mapping/conversion helpers (a very common pattern — DTO mappers, snake_case/camelCase converters, attribute accessors) keep a naturalfn($classFqn, $propertyName)signature while still getting correct, class-specific IDE suggestions.I'd guess this is at minimum a moderate lift, since it likely requires resolving the literal
::classexpression passed at each call site (not just a static config value) before the completion provider runs.