drccrd opened a new issue, #3966:
URL: https://github.com/apache/incubator-kie-tools/issues/3966

   Writing a type name and a dot in a constraint or a consequence — `Rounding.` 
— currently offers the type's **instance** properties, which are the one set 
that cannot legally follow a type name. Nothing offers its constants or its 
static methods, and hovering one describes nothing.
   
   Reproduced against an imported Java class with three bean properties and no 
statics, caret directly after the dot:
   
   ```
   after 'Pet.' -> 3 items [name, friendly, legs]
   ```
   
   So this is a correctness fix as much as a feature: the wrong set is offered, 
and the right one is missing. It applies equally before and after a Maven 
build, so it is not part of the works-before-build trade-off.
   
   ### Why nothing offers them
   
   The member model has two views, and reflection draws the line the same way:
   
   - `ClassMemberIndex.membersOf` — the fact properties, instance members only. 
This is what field completion inside a pattern and hover's member sections 
consume, and it is what the chain walk consumes after a dot.
   - `ClassMemberIndex.memberNames` — every name reachable as `Type.NAME`, 
taken from `Class#getFields()`, statics included. Only the unknown-type lint 
reads it, and it carries names alone: no types, no signatures.
   
   So the information needed to *offer* a static — its type, or a method's 
signature — exists in neither view. `constructorsOf` is the closest precedent 
for signature strings.
   
   ### Why the hard part is already done
   
   Both walks already know whether the head of a dotted chain was a type 
reference or a value:
   
   - `DRLHoverHelper.hoverChain` sets its running type from 
`typeIndex.get(segment)` or `resolveFqcn(segment)` for a type reference, and 
from a binding or an enclosing pattern's field for a value.
   - `DRLCompletionHelper.memberItemsForChain` sets `rootType = head` when the 
head is upper-case-led, and resolves a binding or pattern field otherwise.
   
   Neither propagates that distinction to the member lookup. Doing so is the 
small part of this change.
   
   ### Proposal
   
   Add two methods to the `JavaMemberSource` seam and implement them on both 
sides — reflection in `ClassMemberIndex` (`getFields()` and `getMethods()` 
filtered to static), and the parsed model in `JavaSourceTypeIndex`:
   
   - static fields as name-and-type, so a completion item and a hover can both 
be rendered
   - static methods as signatures, in the shape `constructorsOf` already returns
   
   `JavaSourceType` currently keeps the public static field *names* only (added 
so the unknown-type lint stops calling `Type.CONSTANT` an unknown member before 
a build); that list grows to carry types, and gains the method signatures. The 
parser already sees the modifiers and discards the type today.
   
   Then, in type-reference position, completion and hover consult the static 
view **instead of** the instance view — Java allows only statics there. Only 
the first hop after a type reference is static: in `Rounding.SCALE.precision` 
the second segment is a property of the constant's own type, so instance 
members resume.
   
   ### Non-goals
   
   - **Bare calls through a static import.** `import static 
com.example.Rounding.roundHalfUp;` followed by `roundHalfUp(x)` is a bare 
identifier in an expression, completed through the grammar's own candidates 
rather than the chain walk. Supporting that is separate work.
   - **Inherited statics before a build.** Constants declared on an interface 
or a compiled parent will not appear until the type is compiled, because the 
source-side inheritance walk follows neither. Consistent with the existing 
limitation on inherited members generally.
   - **Nested types.** `Class#getFields()` also surfaces nested type names; the 
source index does not index nested types at all, and this change does not alter 
that.
   
   ### Scope
   
   Roughly 400 lines across seven files and five test files: 
`JavaMemberSource`, `ClassMemberIndex`, `JavaSourceType`, 
`JavaSourceTypeParser`, `JavaSourceTypeIndex`, `DRLCompletionHelper`, 
`DRLHoverHelper`.
   
   Tests should cover: statics offered in type-reference position and instance 
members not; instance position unchanged; hover on a static field showing its 
type and on a static method showing its signature; the second hop reverting to 
instance members; declared-enum constants (already handled by the walk) not 
regressed; and the source and compiled paths agreeing on the same type.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to