SK8 (lenguaje de programación)

El sistema de objetos SK8, al igual que JavaScript , se basaba en prototipos , pero a diferencia de JavaScript, las propiedades de los objetos eran objetos en sí mismas. Por lo tanto, las propiedades no eran simplemente nombres que actuaban como claves para establecer o recuperar valores, sino que además poseían un comportamiento arbitrario. Esto permitía que las propiedades tuvieran un comportamiento inteligente (por ejemplo, activar un motor de inferencia o servir como puntos finales en redes RPC); se podría decir que eran "propiedades inteligentes". La idea era permitir que los programadores de aplicaciones se centraran en manipular los objetos en lugar de tener que aprender las API, que estarían integradas en los objetos. No se implementó un espacio de nombres jerárquico para gestionar los nombres de las propiedades.

Hasta 1989, el lenguaje de scripting de SK8 era Lisp. Posteriormente, se cambió a SK8Script, fuertemente influenciado por HyperTalk . Muchas de las diferencias entre SK8Script y HyperTalk pueden considerarse una generalización de los conceptos de HyperTalk, eliminando la estrecha integración con objetos específicos del universo HyperCard y reemplazándola por una sintaxis generalizada que podía interactuar con cualquier objeto.

Al igual que HyperTalk, un concepto fundamental del sistema SK8Script son los "contenedores", que equivalen aproximadamente a los objetos en los sistemas convencionales, y el sistema de "fragmentación" que permite identificar y enumerar dichos contenedores. HyperTalk introdujo la idea de ofrecer múltiples formas de acceder a objetos y colecciones, permitiendo al programador seleccionar la sintaxis que le pareciera más natural en cada contexto y, posteriormente, utilizar una sintaxis completamente diferente en otros lugares. SK8Script ofrecía un sistema similar.

El universo de SK8 se componía de un sistema multimedia que utilizaba Actores en un Escenario. Los Actores eran objetos basados ​​en el prototipo de objeto Actor, que contenía la estructura básica necesaria para proporcionar soporte gráfico 2D, como la ubicación y el tamaño del objeto. Los Actores se hacían visibles al colocarlos en el Escenario, un objeto de fondo invisible que capturaba los eventos del usuario para proporcionar interactividad. En SK8, una ventana tradicional era un objeto gráfico como cualquier otro. Cuando un Actor estaba en el Escenario, podía comportarse como una ventana. ^{[ 4 ]} Era fácil diseñar objetos complejos que se comportaran como ventanas (por ejemplo, una ventana con forma de rosquilla; la opacidad de su agujero era del 0 %, con un texto desplazándose o una película reproduciéndose dentro de su marco). Un objeto conocido como el "halo" proporcionaba controles de redimensionamiento y otros widgets para su manipulación en un entorno de desarrollo visual. ^{[ 5 ]}

Todos los actores SK8 podían contener otros actores. ^{[ 6 ]} La jerarquía podía navegarse usando expresiones de fragmentación, por lo que se podía set the visible of the first Rectangle in CoolOval to true. Los objetos podían hacerse visibles en la interfaz de usuario moviéndolos al escenario usando el insertcomando, como insert CoolOval into the stage, lo que haría aparecer tanto el óvalo como el rectángulo. ^{[ 7 ]}

Las GUI se construían exclusivamente a partir de Actores. Un objeto similar a una ventana podía crearse a partir de un rectángulo opaco que contenía otros objetos (por ejemplo, botones de cierre, widgets). ^{[ 8 ]} El estilo de dibujo de cada Actor estaba controlado por un Renderizador, que facilitaba el proceso de construcción de la GUI. Por ejemplo, el BevelRenderer podía utilizarse para biselar los bordes alrededor de un Actor, produciendo un efecto similar al de los controles de Windows 3.x o la barra de título de NeXTSTEP . Otros renderizadores incluían rellenos de color e imagen, degradados, mosaicos y fusiones. ^{[ 9 ]} Aunque no existía diferencia en términos de programación, los objetos básicos como los rectángulos se clasificaban como "actores geométricos", mientras que los elementos de GUI más tradicionales, como los botones, se conocían como "actores de interfaz". ^{[ 10 ]}

El escenario capturaba eventos generados por el usuario, como clics del ratón y pulsaciones de teclas, y los enviaba a los actores. La jerarquía visual determinaba qué objeto recibiría primero el mensaje: el escenario estaba ordenado por Z y los objetos más cercanos al frente recibían los mensajes primero. Los mensajes podían transmitirse hacia arriba en la jerarquía de clases/prototipos mediante el do inheritedcomando. ^{[ 11 ]}

Project Builder era un entorno para crear entornos de desarrollo visual. Proporcionaba edición de código, depuración, gráficos y biblioteca de componentes inteligentes, soporte para la segmentación en tiempo de ejecución y un sistema de creación de interfaz gráfica de usuario de manipulación directa. Un elemento clave del sistema Builder era el panel "Overviewer", que contenía una lista categorizada de todos los objetos del proyecto abierto. Estos incluían bibliotecas, funciones y métodos creados por el usuario, variables, etc. ^{[ 12 ]} Estos podían examinarse y editarse haciendo doble clic sobre ellos o haciendo clic en un menú emergente asociado que aparecía en el objeto cuando se seleccionaba en el constructor de GUI. ^{[ 8 ]} El editor de objetos que aparecía mostraba las "propiedades" del objeto ( variables de instancia y de clase ) en un panel y sus "controladores" ( métodos ) en otro. ^{[ 13 ]}

El constructor de GUI incluía un sistema basado en arrastrar y soltar para construir objetos visuales. ^{[ 14 ]} SK8 no tenía "pantallas" tradicionales; utilizaba un objeto "Escenario" invisible que servía como fondo para gestionar eventos y objetos visuales. Un aspecto interesante era que no se necesitaban ni se esperaban ventanas, en el sentido tradicional, para mostrar nada. De hecho, cualquier objeto visual podía tener un comportamiento similar al de una ventana (a través de su función de arrastrar y soltar y otras propiedades inteligentes). SK8 sí incluía un sistema para editar y programar barras de menú completas , una característica de la que carecía HyperCard. Otra característica solicitada con frecuencia en HyperCard era un editor de medios, que permitía mover recursos de Macintosh dentro y fuera del proyecto. SK8 integró esta funcionalidad en el IDE. Otros componentes del sistema incluían un sistema de documentación en línea, listas de objetos y comandos de todo el sistema, y ​​las ventanas del editor de código y del depurador. ^{[ 15 ]}

SK8Script ofrecía un sistema para llamar a funciones del sistema operativo y obtener resultados , lo que le permitía interactuar más directamente con Macintosh Toolbox . En HyperCard, la interacción con código arbitrario de Toolbox se gestionaba mediante recursos de código personalizados conocidos como XCMD y XFCN, que encapsulaban la funcionalidad en una caja negra . Estos se llamaban y devolvían en una sola operación, siendo las operaciones internas invisibles. Con SK8, SK8Script podía interactuar directamente con el código encapsulado, estableciendo variables, llamando a funciones y devolviendo resultados. El código externo también podía llamar a SK8Script, examinando y estableciendo variables o llamando a funciones. ^{[ 16 ]}

• Entorno de creación multimedia SK8 . Apple. 1995.
• Manual de usuario del SK8 (PDF) . Apple. 1995.
• Spohrer, Jim (abril de 1998). "Investigación educativa de ATG: El hilo conductor de las herramientas de autoría".". Boletín SIGCHI . 30 (2). Asociación para la Maquinaria de Computación. doi : 10.1145/279044.279173 . S2CID 15281183 . 

• Patente estadounidense 5737554 , Epelman-wang, Hernan; Kleiman, Ruben y Vronay, David Patrick, "Sistema y método para utilizar la sensibilidad a los objetos para seleccionar objetos generados por computadora", publicada el 7 de abril de 1998, asignada a Apple Computer, Inc. 
• Patente estadounidense 5450540 , Spohrer, James C.; Richards, Tyde B.; Vronay, David P.; Chipkin, Adam M.; Kleiman, Ruben J. y Miller, Mark L., "Interfaz gráfica para actores con restricciones que interactúan", publicada el 12 de septiembre de 1995, asignada a Apple Computer, Inc. 

• Spohrer, James C.; Cypher, Allen; James, Arthur; Kleiman, Ruben; Ohmaye, Enio; Smith, David C. (2-5 de octubre de 1994). «Cómo hacer que el software "complejo" sea personalizable». Actas de la Conferencia Internacional IEEE sobre Sistemas, Hombre y Cibernética . Vol.  2. San Antonio, Texas, EE. UU. págs. 1404-1408 . doi : 10.1109/ICSMC.1994.400042 . ISBN  0-7803-2129-4.{{cite book}}: CS1 mantenimiento: falta el editor de ubicación ( enlace )
• Spohrer, Jim; Sumner, Tamara; Buckingham Shum, Simon (octubre de 1998). "Herramientas de autoría educativa y la economía de objetos educativos: Introducción a este número especial del Grupo Este/Oeste" . Journal of Interactive Media in Education . 1998 (2): Art. 10. doi : 10.5334/1998-10 .