El 29 de agosto de 2024, el equipo lanzó Language Server v2.6.0, que incluye más mejoras para la autocompletación de código (también conocida como intellisense). Eso significa que #dim, aunque sigue siendo útil, ya no es tan necesario. En mi opinión, eso es algo bueno.

Esta publicación del año pasado (Intellisense y autocompletación de código en VS Code ObjectScript) hablaba sobre el uso de #dim para la autocompletación de referencias de objetos (OREFs). #dim siempre ha sido útil tanto para Studio como para VS Code. Pero el año pasado, VS Code ObjectScript estaba ligeramente detrás de Studio en esta área, y #dim ayudaba a cerrar esa brecha. Pero ahora, VS Code ha superado a Studio. Hay autocompletación automática de código para las siguientes variables mostradas en negrita:

• Variables creadas usando %New() o %OpenId(). set per = ##class(Sample.Person).%New()
• Variables como argumentos de un método. Method M1(per as Sample.Person)
• Variables devueltas por un método. set rs = ##class(SQL.Statement).ExecDirect(args)
• Variables creadas mediante una propiedad de referencia. set owner = account.Owner
• Variables para %DynamicObject y %DynamicArray. set obj = {}, arr = []
• ACTUALIZACIÓN 10/2/2024: %Variables que son OREFs que se proporcionan como parte del contexto de un método. Ejemplos: %sqlcontext en un método de clase que usa [SqlProc], %code en un método generador, %session en ciertos métodos llamados desde aplicaciones web. 

Así que #dim ya no es necesario para esos casos. Se me ocurren un par de casos restantes en los que #dim es útil.

El caso de abajo es ahora manejado por una mejora (arreglado el 10/2/2024, disponible poco después).

Cuando se proporciona una variable OREF como parte del contexto de un método. Un ejemplo de esto es cuando un método de clase se declara como un procedimiento almacenado. La variable %sqlcontext se proporciona automáticamente. Usando #dim se habilitará el completado de código para esa variable.

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

1. Para la variable de excepción en un bloque catch. Hay varias clases de excepción, y es posible hacer clases de excepción personalizadas. El uso de #dim permitirá completar el código correctamente.

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

Dato adicional sobre #dim: Sé que algunos equipos de desarrollo prefieren usar #dim para la mayoría o todas las variables (no solo OREFs), utilizándolo para declarar (hacer más claro) el propósito de cada variable. Para esos equipos, también es útil que VS Code ofrezca la opción de hacer clic derecho en una variable y seleccionar "Ir a declaración" para saltar a la declaración de #dim de esa variable, si existe.

¡Hey! Si leíste hasta aquí, prueba la encuesta sobre #dim a continuación.

Que todos vuestros días como desarrolladores sean brillantes y no...

😁