Skip to content

Record constructor signatures on initial state transitions - #1

Open
CatarinaGamboa wants to merge 1 commit into
mainfrom
feat/112-constructor-signatures
Open

CatarinaGamboa wants to merge 1 commit into
mainfrom
feat/112-constructor-signatures

Conversation

@CatarinaGamboa

Copy link
Copy Markdown
Contributor

Summary

Record the constructor signature on each initial state transition so the VS Code diagram can show which constructor leads to each state. This covers overloaded constructors, conditional constructor postconditions, interface declarations for external refinements, and constructors that use the default first state.

Supports liquid-java/vscode-liquidjava#112. The matching extension change is in a separate PR.

Verification

  • mvn test passed: 20 tests, including overloaded constructors that reach the same state and constructors without explicit state annotations.
  • A locally built server and VS Code webview rendered both new MultipleInitialStates() and new MultipleInitialStates(int) on their respective arrows.

Integration note

The extension currently depends on the published liquidjava-fsm 0.1.0 artifact. For local end-to-end testing, install this branch with mvn install before rebuilding the extension server. A new FSM artifact version and corresponding server dependency update will be needed before the extension change can be released.

String className, String firstState) {
Collection<? extends CtExecutable<?>> constructors = getConstructorElements(ctType, className);
if (constructors.isEmpty()) {
String implicitConstructor = ctType instanceof CtClass<?> ? "new " + className + "()" : null;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the "new" + className really necessary? It's a bit verbose, especially when there are a lot of constructors.

Image

How about just constructor(params) or just (params)?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think this is the most accurate description, but its true that it might be a bit verbose, I would say to keep this and then see if its too verbose for the most complex examples we can reduce it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants