Aprendiendo ObjectScript como un Desarrollador Nuevo: Lo que me Habría Gustado Saber

Me uní a InterSystems hace menos de un año. Sumergirme en ObjectScript e IRIS fue emocionante, pero también estuvo lleno de pequeñas sorpresas que me hicieron tropezar al principio. En este artículo recojo los errores más comunes que yo, y muchos compañeros nuevos, cometemos, explico por qué ocurren y muestro ejemplos concretos junto con soluciones prácticas. Mi objetivo es ayudar a otros desarrolladores que empiezan a ahorrar tiempo y evitar los mismos obstáculos en el camino.

 

1. Perderse entre las clases del sistema y no saber por dónde empezar

El problema: ObjectScript/IRIS viene con muchas clases y paquetes de sistema (%Library, %SYS, %Persistent, %SQL, etc.). Como nuevo desarrollador, es difícil saber qué clase o patrón se ajusta a una tarea. Recuerdo intentar encontrar una clase persistente adecuada y no estar seguro de si debía extender %Persistent o usar una clase de tipo registro.

Por qué importa: Elegir un enfoque equivocado desde el inicio hace que el código sea más difícil de mantener y se integre peor con las funciones de IRIS (índices, seguridad, SQL).

Consejo: Partid siempre de la necesidad concreta (¿guardar registros? ¿exponer SQL? ¿compartir objetos entre procesos?) y luego buscad en la Class Reference la capacidad relevante (persistencia, índices, colecciones). Usad Studio o la extensión de InterSystems para VS Code para explorar las clases de manera interactiva e inspeccionar ejemplos.

 

2. Sobrecarga con la documentación: no saber las palabras clave correctas

El problema: La documentación es muy completa, pero si no conocéis el nombre exacto de la clase o el término, las búsquedas devuelven muchas páginas no relacionadas. Al principio pasaba mucho tiempo porque aún no conocía los términos canónicos.

Por qué importa: Perdéis tiempo y podéis acabar implementando patrones poco óptimos.

Consejo:

• Buscad en la Developer Community ejemplos prácticos (buscad por “persistent class example”, “ObjectScript transaction TSTART example”, etc.).
• Usad la extensión de InterSystems para VS Code, que puede saltar directamente a las definiciones de clases.
• Al buscar en la documentación, combinad nombres de clases y acciones: por ejemplo, “%Persistent property index example”.

 

3. Olvidar .. al llamar a un método local

El problema: Llamar a un método de la misma clase sin .. provoca que la llamada no se reconozca en tiempo de ejecución.

Incorrecto:

Class MyClass Extends %Persistent { 
   Method DoWork() 
   { 
       Do Hello()  // wrong: this is not a local method invocation
   } 
   Method Hello()
   { 
       Write "Hello", ! 
   } 
}

Correcto:

Method DoWork() {
   Do ..Hello()  // correct: local method call 
}

Consejo: Cuando os aparezcan errores de “Unknown routine” al intentar usar métodos que veis en la clase, comprobad si habéis usado .. para las llamadas a métodos de la propia clase.

 

4. Confusión entre globals y variables locales

El problema: ObjectScript distingue entre globals (persisten entre sesiones, por ejemplo ^MyGlobal) y variables locales (en memoria, con un alcance limitado). Los nuevos desarrolladores suelen usar uno cuando en realidad necesitan el otro.

SET localVar = 10    // exists only during the current process/session
SET ^globalVar = 20  // persists in the database across processes and sessions

Consejo: Usad clases persistentes para los datos que deban almacenarse a largo plazo. Limitad el uso de globals solo a necesidades muy específicas de bajo nivel o cuando entendáis bien sus consecuencias.

 

5. Codificar directamente en globals en lugar de usar clases persistentes

El problema: Mi primer instinto fue el “rápido y sucio”: escribir directamente en ^MyGlobal. Eso funciona, pero evita las ventajas basadas en clases: esquema, índices, acceso vía SQL y seguridad.

Un mejor enfoque:

Class Person Extends %Persistent 
{ 
    Property Name As %String; 
    Property DOB As %Date; 
}

Consejo: Dad siempre preferencia a las clases %Persistent para los datos de la aplicación. Os ofrecen un modelo más limpio e integran automáticamente con SQL e índices.

 

6. Ignorar las transacciones (TSTART / TCOMMIT)

El problema: A veces los desarrolladores realizan varias escrituras pensando que son atómicas. Sin un control explícito de transacciones, un fallo parcial puede dejar los datos en un estado inconsistente.

TSTART 
// multiple updates 
TCOMMIT

Consejo: Identificad las unidades lógicas de trabajo y envolvedlas en transacciones. Si algo puede fallar a mitad, usad TSTART / TROLLBACK / TCOMMIT. Tened en cuenta que IRIS soporta transacciones anidadas: varias llamadas a TSTART incrementan el nivel de transacción, y todos los niveles deben ser confirmados (o revertidos) antes de que los cambios sean definitivos.

 

7. Malentender las opciones de SQL: Embedded SQL vs %SQL.Statement

El problema: Embedded SQL (bloques UPDATE, SELECT dentro de ObjectScript) y la API %SQL.Statement están disponibles; elegir sin conocer sus pros y contras puede llevar a un código poco claro o difícil de mantener.

Recomendación: Usad Embedded SQL para consultas fijas/estáticas dentro de rutinas; usad %SQL.Statement cuando necesitéis construir y ejecutar SQL de forma dinámica.

 

8. Saltarse un manejo adecuado de errores

El problema: No usar TRY/CATCH ni señalizar los errores correctamente dificulta la depuración y reduce la fiabilidad del código.

TRY 
{ 
   // code that may fail 
} CATCH ex 
{  
   Write "Error: ", ex.DisplayString(),! 
}

Consejo: Envolved siempre las operaciones de riesgo (I/O, llamadas externas, SQL dinámico) con manejadores de errores y registrad mensajes informativos.

 

Notas finales

Al principio escribía en globals por comodidad y más tarde tuve que dedicar tiempo a refactorizar hacia clases persistentes. Esa refactorización me enseñó el valor de diseñar los modelos de datos desde el principio y de usar las herramientas que ofrece IRIS.

Mis mejores hábitos ahora son: hacer pequeños experimentos, buscar con frecuencia en la Developer Community y tener siempre presentes las transacciones y el manejo de errores desde el inicio.

Si sois nuevos: tratad vuestras primeras tareas como experimentos, cread pequeñas clases persistentes, probad con SQL incrustado sencillo y usad el Management Portal y el explorador de clases de VS Code para inspeccionar las clases del sistema. Haced preguntas en la Developer Community; muchos otros se han encontrado con las mismas “trampas” al empezar.

Para más información: consultad la documentación oficial de ObjectScript y la Developer Community para ejemplos y patrones.