An alternative for Ballerina Shell type signature generation

[kdsuneraavinash]

Hello,

For Ballerina Shell, currently is follows an approach where each code snippet is wrapped (with generated Ballerina code) before compiled. However, this wrapper includes a cast statement for previously defined var-dclns. (eg: Type v = <Type> load("x")
So, the variable type should be "writable", in the sense that the variable name should be generatable to be a valid code segment.

However, the issue is with var types. If the variable is defined using var, an approach is to get its TypeSymbol using semantic API and use the signature() method to generate the type signature. But if the TypeSymbol is an imported type, this approach will not work, because currently, the type signature will return something of format abc/pqr:1.0:Type which is not a valid syntax that can be included in a code segment.

So the current implementation of the shell has a TypeSignatureTransformer which does exactly what the signature() does, but converts the ErrorTypeSymbols and TypeReferenceTypeSymbols so that they will use imported module names correctly. Is there a way to reduce this code duplication, because in the end, TypeSignatureTransformer only needs to convert the said 2 types in a custom way, all others have to follow the same logic as signature()?

There is also a PR to use the signature() but replace imported names from the generated string, but I'm not sure that is the best approach. #28301

Any thoughts or ideas would be great.

[pubudu91]

I think we should probably provide two separate methods for this. Maybe change the behaviour of the current signature() method to return the signature as we write it in code and another method, maybe fqSignature() which will return the fully qualified signature. @rasika WDYT?

[rasika]

Current API is serving both cases(without loosing package info). We need FQ names since auto-imports needs to be captured through the text. If required, you can just remove the FQ names using a simple regex. In langserver we are using

ballerina-lang/language-server/modules/langserver-core/src/main/java/org/ballerinalang/langserver/common/utils/FunctionGenerator.java

Line 61 in e002057

public static String generateTypeDefinition(ImportsAcceptor importsAcceptor,

to capture the imports required while simplifying the text.

I am +1 for diff. apis; I would suggest having it as a parameter, something similar to signature(boolean qualifiedNamesEnabled) or signature(boolean withQualifiedNames) to change the behavior of the api

[pubudu91]

After a further chat with @nadeeshaan @rasika and @kdsuneraavinash, decided not to go through with this change for now since the use cases for the shell are manageable with the current signature() implementation.