Improved code completion for object reference variables in VS Code ObjectScript

On 2024-08-29, the team released Language Server v2.6.0, which includes more improvements for code completion (aka intellisense). That means that #dim, while still useful, is hardly necessary anymore. That's a good thing in my opinion.

This post from last year (Intellisense and code completion in VS code objectscript) talked about using #dim for code completion for OREFs. #dim has always been useful for both Studio and VS Code. But last year, VS Code ObjectScript was slightly behind Studio in this area, and #dim helped bridge that gap. But now, VS Code has surpassed Studio. There is automatic code completion for the following variables shown in bold:

• Variables created using %New() or %OpenId(). set per = ##class(Sample.Person).%New()
• Variables as arguments of a method. Method M1(per as Sample.Person)
• Variables returned by a method. set rs = ##class(SQL.Statement).ExecDirect(args)
• Variables created using a reference property. set owner = account.Owner
• Variables for %DynamicObject and %DynamicArray. set obj = {}, arr = []
• UPDATE 10/2/2024: %Variables that are OREFs that are provided as part of the context for a method. Examples: %sqlcontext in a class method that uses [SqlProc], %code in a generator method, %session in certain methods called from web applications. 

So #dim is no longer necessary for those cases. I can think of a couple of one remaining case where #dim is helpful.

The case below is now handled by an enhancement (fixed on 10/2/2024, available soon afterwards).
When an OREF variable is provided as part of the context for a method. One example of this is when a class method is declared as a stored procedure. The %sqlcontext variable is automatically provided. Using #dim will enable code completion for that variable.

ClassMethod ByPhone(begin As %String = "", dob As %String = "") [ ReturnResultsets, SqlProc ]
{
    #dim %sqlcontext as %Library.ProcedureContext
    <some code>
    do %sqlcontext.AddResultSet(rs)
}

1. For the exception variable in a catch block. There are several exception classes, and it's possible to make custom exception classes. Using #dim will enable proper code completion.

    catch ex {
        #dim ex as <some system or custom exception class>
        if ex.DisplayString()
    }

Extra #dim tidbit: I know that some development teams like to use #dim for most/all variables (not just OREFs), using it to declare (make it clear) what the purpose of each variable is. For those teams, it's also nice that VS Code provides the ability to right-click a variable and click "Go To Declaration" to jump to the #dim statement for that variable, if one exists.

Hey! If you read this far, try the #dim poll below.

May all your developer days be bright and not...

😁