Constructor for classes

[ejfasting]

Hello,

I've added classes to my language, and now want to add some constructor-logic to them. This is how the class is defined in the grammar:

Class returns NamedElement: 
    {infer Class} 'Class' name=ID '{'
    members+=ClassMember*
'}';

ClassMember: MethodMember | FieldMember;

MethodMember:
    returnType=[Class:ID] name=ID '(' (parameters+=Parameter (',' parameters+=Parameter)*)? ')' ';';

Parameter: type=[Class:ID] name=ID
;

FieldMember:
    type=[Class:ID] name=ID ';'
;

VariableDeclaration would then become:

VariableDeclaration returns NamedElement:
    {infer VariableDeclaration} type=[Class:ID] name=ID (assignment?='=' value=(Expression))? 
;

I then took the Expression-logic from the lox-sampe, and it works pretty nicely for assigning variables.

In my case i need to be able to have this syntax:

Map m = Map("key", "value");
Map m2 = Map("key");

This means that i need to have a constructors with the same name as the class. I initially thought I could edit the Class to have this grammar:

Class returns NamedElement: 
    {infer Class} 'Class' name=ID ('(' (parameters+=Parameter (',' parameters+=Parameter)*)? ')')? '{'
    members+=ClassMember*
'}';

Which would make it possible to create some 'special classes' like this:

/** Constructor class*/
Class Map(String key, String value){}

/** Other Constructor class*/
Class Map(String key){}

The completionItems gets filtered to only show one of them, thought, so is there something i can override to show them all?

And when making validations for this, is it possible to 'fetch' the parameters from the Class, and from that validate that the parameters passed inn is of valid type?

I'm open to reworking this as well, if there are better/other options for how to solve this :)

/e

[ejfasting]

After taking a closer look i figured its better to not have multiple completionitems with the same name, and just do validations of the parameters instead. The documentation/comment can explain the overloads.

Was able to add/inject them through the defaultcompletionsprovider/getcompletion(), but it behaved differently depending on position so it seems safer to avoid going down this path.

[msujew]

I was about to write, that it's likely not a good idea to have different overloads of the same name in the completion. Instead, you can use the LSP SignatureHelpProvider (and AbstractSignatureHelpProvider) to provide all the different overloads of your constructors to the user:

langium/packages/langium/src/lsp/signature-help-provider.ts

Lines 17 to 26 in 68c0fa3

	export interface SignatureHelpProvider {
	/**
	* Handles a signature help request
	*/
	provideSignatureHelp(document: LangiumDocument, params: SignatureHelpParams, cancelToken?: CancellationToken): MaybePromise<SignatureHelp | undefined>;
	/**
	* Options that determine the server capabilities for a signature help request. It contains the list of triggering characters.
	*/
	get signatureHelpOptions(): SignatureHelpOptions;
	}

[ejfasting]

Make sense, and it looks like a nice way to solve it:

I notice the provideSignatureHelp() gets the whole LangiumDocument, and you do some 'magic' in findLeafNodeAtOffset/binarySearch to find the node (in my case the class with the constructor).

I have Multiple dependant languages, which means the classes (with the constructors) are defined in the definition-language, and a part of a builtin library.
The implementation-language does not have the capability to create new classes, so I'm thinking it might be a performance increase to only look in the builtin-library.
Any magic i can do to achieve this? I'm guessing not, but its worth a shot :)

Appreciate the help!

/e

[msujew]

Any magic i can do to achieve this? I'm guessing not, but its worth a shot :)

Maybe no magic, but at least a recommendation: If it's part of the builtin library, you can usually perform some aggregation of the builtin data to make it easier to consume in other services. We often do that for scope data. In your case, you might want to prepopulate a map or similar data structure to quickly create the LSP responses.

[ejfasting]

Maybe no magic, but at least a recommendation: If it's part of the builtin library, you can usually perform some aggregation of the builtin data to make it easier to consume in other services. We often do that for scope data. In your case, you might want to prepopulate a map or similar data structure to quickly create the LSP responses.

Wouldnt it then make the most sense to remove it as a builtin, and rather parse it myself during startup and extend the providers to include the classes (where it's needed)? I suppose Langium would still search the builtin from time to time to resolve 'stuff', so I could quickly be doing the same thing as langium itself does under the hood (?)

I did a test, and it doesnt look to hard to resolve this:

protected override getSignatureFromElement(element: AstNode, cancelToken: CancellationToken): MaybePromise<SignatureHelp | undefined> {
        if (!isConstructorCall(element)) {
            return undefined;
        }

        const signatureHelp: SignatureHelp = { signatures: [], activeSignature: undefined, activeParameter: undefined };

        const constructorCall = element as ConstructorCall;
        constructorCall.type.ref?.constructors.forEach(element => {
            const label = `${element.$container.name}(` +
            element.params.map(p => `${p.type.$refText} ${p.name}`).join(', ') +
            `)`;
            
            const option = SignatureInformation.create(label, "This is the documentation", ParameterInformation.create([constructorCall.type.$refText.length + 1, label.length - 1]));
            signatureHelp.signatures.push(option);
        });
        return signatureHelp;
    }

But its a good thing to consider, I'll probably revisit this if i bump into performance issues :) Thank you!