Telescript (lenguaje de programación)

Telescript se basó en el concepto de pequeños programas, conocidos como agentes , que interactuarían con servicios informáticos denominados lugares. Todos ellos se ejecutaban en un clúster de uno o más servidores que albergaban lo que se denominaba una nube Telescript. El dispositivo portátil del usuario era uno de esos lugares, aunque con capacidades limitadas. El modelo asumía que la mayor parte de la información y los servicios serían proporcionados por lugares que se ejecutaban en servidores más grandes alojados por proveedores de comunicaciones como AT&T. Incluso los primeros documentos se referían a esto como " ejecutarse en la nube" . ^{[ 1 ]} Los programas orientados al usuario consistirían en varios de estos agentes, que podrían ejecutarse localmente, en los hosts del proveedor, o incluso reenviarse a servidores de terceros. Para coordinar las comunicaciones, Telescript también incluía los conceptos de telenombre , que identificaba de forma única a los usuarios, y teledirecciones , que identificaban el dispositivo incluso cuando se movía entre redes. ^{[ 6 ]}

Por ejemplo, consideremos una aplicación de compras donde el usuario solicita encontrar precios para una nueva parrilla que desea comprar. En un modelo cliente-servidor tradicional , la aplicación formularía varias consultas, las enviaría a diversos servicios y luego recopilaría los resultados y los mostraría. En el modelo Telescript, la aplicación crearía un nuevo agente con los datos de la solicitud, lo personalizaría con el nombre y la dirección del usuario y lo enviaría a una tienda en un servidor para su procesamiento. Este servidor podría entonces gestionar la solicitud directamente o transferir el agente a otros lugares, como las tiendas de los vendedores, para su posterior procesamiento. Los resultados podrían almacenarse en los campos de datos internos del agente y enviarse de vuelta a través de la red al dispositivo del usuario, o bien se podría crear un nuevo agente "mensajero" que transportara únicamente los datos de los resultados y los enviara de vuelta para minimizar la transferencia de datos en la red. ^{[ 7 ]}

El modelo también se diferencia de las soluciones tradicionales en la forma en que se produce el intercambio de datos en el caso de programas que interactúan. Por ejemplo, si el usuario decide comprar una de las barbacoas que encontró en su búsqueda anterior, en un sistema convencional la tarea de completar los formularios de pedido y confirmar el pago se realizaría mediante comunicaciones directas entre el dispositivo del usuario y el servidor remoto, lo que requeriría un canal de comunicación "en vivo" durante todo el proceso. En el modelo Telescript, se envía un nuevo agente con la información necesaria para completar la compra al establecimiento del vendedor, este interactúa con el establecimiento o con los agentes del vendedor y luego regresa con el resultado (éxito o fracaso). Las comunicaciones principales se producen entre los agentes y los establecimientos en el servidor remoto, por lo que la comunicación a través de la red solo es necesaria al inicio y al final del proceso. ^{[ 8 ]}

Telescript era orientado a objetos (OO) y utilizaba una serie de términos poco comunes para describir el estado y las comunicaciones de los objetos. Los atributos corresponden a lo que otros lenguajes denominan variables de instancia o campos. Las llamadas a métodos se conocían como solicitudes , y la ejecución de la implementación de un método se conocía como realizarla . Todas estas llamadas siempre respondían con un mensaje que indicaba éxito o fracaso; el objeto solicitante podía, opcionalmente, interceptar esos mensajes y responder a ellos . Las indicaciones sobre cómo pasar los datos dentro y fuera de las llamadas a métodos se conocían como restricciones , y abarcaban las comunes " por referencia " y " por valor ", entre otras. ^{[ 9 ]}

Telescript generalmente no mantenía estado en lo que respecta al ciclo de vida de los datos. Todos los datos dentro del programa, tanto las variables de instancia como las locales, siempre se serializaban. Los agentes podían invocarse o suspenderse en cualquier momento sin perder su estado. Este mismo mecanismo también permitía que los agentes se comunicaran fácilmente entre hosts.

Aunque el control y la disposición de Telescript se inspiraron en C, su sintaxis precisa era considerablemente diferente. Una diferencia obvia fue la sustitución de las llaves de estilo C por paréntesis a nivel de definición, conservando las llaves para agrupar sentencias dentro de sentencias de lógica y control de flujo , y el uso de los dos puntos para separar un nombre de su definición. El siguiente código define la interfaz para objetos del tipo Pie : ^{[ 10 ] [ N 1 ]}

 Pastel: interfaz(Objeto) = ( público nombre: Cadena; inicializar: op(nombre: String); );

Nótese el uso de la palabra clave op, que corresponde a functiono subque se encuentra en otros lenguajes. La implementación de Pie podría usarse en uno o más classobjetos, que pueden organizarse en modulesde forma similar a la construcción de Visual Basic .NETnamespace . #includese utiliza para importar archivos de encabezado, pero la importación es local a modules, no al archivo en su conjunto. ^{[ 11 ]}

Los conceptos de agente y lugar de Telescript se invocaban simplemente creando subclases de esas dos clases, Agente y Lugar, ambas subclases de Proceso. Para mayor claridad del código, se podían colocar ambas en un solo archivo, e incluso agruparlas en un solo módulo. El siguiente código define los agentes necesarios para implementar una tienda que vende pasteles: ^{[ 12 ]}

 PieStoreModule: módulo = ( #incluir "pie.i" PieBuyer: clase(Agente) = ( público en vivo: patrocinado op() = { *.ir(*.destino); miPie = lugar@PieVendedor.sellPie(); *.go(*.originPlace); }; ); Vendedor de tartas: clase(Lugar) = ( público venderPie: op() Pie = { aPie: Pastel | Ninguno; unPie = *.getPieFromStock; si (aPie = nil) { PieBuyer(*.distributorTicket, Permit(nil)); aPie = *.waitForPie(); devolver un pastel; }; }; ); );

El objeto PieBuyer, un Agente, contiene un único método, live, el método de inicio estándar utilizado por todos los Agentes. ^{[ 13 ]} Simplemente crear un PieBuyer e invocarlo hará liveque se llame al método, de una manera similar a la newoperación que se encuentra en la mayoría de los lenguajes OO, aunque este método se llama después de la configuración. El * reemplaza lo que se implementa más comúnmente como selfo Me, refiriéndose al objeto en sí, en este caso el agente PieBuyer. El código básicamente dice que cuando se crea, el objeto debe enviarse a sí mismo (*.go) a la ubicación que se le envió durante la creación (*.destination). Una vez allí, debe indicarle al objeto de lugar correspondiente, en este caso un PieSeller, que venda Pie. Cuando ese comando se complete, el agente regresará a su lugar de origen. La aplicación que lo invocó puede entonces examinar los resultados inspeccionando la variable myPie. ^{[ 12 ]}

El objeto PieSeller, un Place, también contiene un único método. sellPieEste define una variable local llamada aPie, que se define como un objeto Pie, o "nada", que se usa en caso de que no haya pasteles. Luego intenta asignar un valor a aPie llamando a su propio método getPieFromStock (no se muestra aquí) y luego verifica si este devolvió un valor. Si no lo logra, por ejemplo, si el stock está vacío, crea un nuevo objeto PieBuyer, envía la solicitud a otra tienda y espera una respuesta. Esa tienda podría reenviar la solicitud a otra, y así sucesivamente. Cuando esta cadena de eventos concluye, ya sea con un pastel o sin éxito, el lugar PieSeller finalmente devuelve el PieBuyer que lo llamó. ^{[ 12 ]}

Los objetos normalmente son "propiedad" del lugar que los creó. La propiedad también confiere capacidades y configuraciones de seguridad. El lenguaje puede tomar posesión de un objeto a través de la own {}construcción, o en este caso, usar la sponsoredpalabra clave para indicar que debe ejecutarse bajo la propiedad del lugar en el que se está ejecutando. Esto podría usarse, por ejemplo, para otorgar al agente la capacidad de ver el stock en el inventario, valores que de otro modo serían privados. Usar sponsoredes exactamente el mismo resultado que colocar el código en un own {}bloque, pero permite que esto tenga lugar en el llamador. ^{[ 14 ]}

Telescript incluye varios tipos de colecciones integradas, Set, List, Dictionary, y Collection, el último de los cuales es esencialmente una lista con índices de texto (la mitad de un diccionario). Una fuente común de errores en Telescript era que, si bien una colección en su conjunto podía devolverse a un agente, los elementos individuales dentro de ella pertenecían al lugar. Por lo tanto, si se usaba return MyCollection[someIndex];, llegaría al dispositivo del usuario como nulo. La solución fue una sintaxis adicional, las sugerencias DictOwnedy ColOwned, que hacían que la propiedad de los valores devueltos cambiara al regresar, y por lo tanto se serializara en los resultados al regresar al lugar original. ^{[ 15 ]}

Las subclases se conocían como sabores ; la clase PieBuyer descrita anteriormente es un sabor de Agent. Telescript también incluía el concepto de clases mix-in , que ofrecían características similares a la herencia múltiple al permitir la creación de clases que contenían solo código que luego podía incluirse en otras clases. Las clases mix-ins no eran sabores. ^{[ 16 ]}

Al igual que muchos lenguajes modernos de programación orientada a objetos, Telescript separó la interfaz de la implementación, colocándolas en .iarchivos para la interfaz y .tarchivos para la implementación (t como en "t"elescript). De manera poco común, el lenguaje también definió un tercer tipo de archivo, .d, que combinaba varios .iarchivos. ^{[ 17 ]} El código compilado se colocaba en un .sarchivo, que era guiado por las instrucciones del enlazador en un .larchivo. ^{[ 18 ]} El marco de aplicación externo permitía que Telescript llamara al código C++ . ^{[ 19 ]}