SK8 (pronunciado "skate") fue un entorno de creación multimedia desarrollado en el Advanced Technology Group de Apple desde 1988 hasta 1997. Fue descrito como "HyperCard con esteroides", [1] combinando una versión del lenguaje de programación HyperTalk de HyperCard con una plataforma de aplicaciones orientada a objetos moderna . El objetivo del proyecto era permitir a los diseñadores creativos crear aplicaciones complejas e independientes. Los componentes principales de SK8 incluían el sistema de objetos, el lenguaje de programación , las bibliotecas de gráficos y componentes, y el Project Builder , un entorno de desarrollo integrado .
Durante gran parte de su historia, SK8 siguió siendo un proyecto de investigación e inspiró varios otros proyectos de Apple como AppleScript , además de usarse como plataforma de creación de prototipos. Aunque alrededor de 1993 la División de Productos de Apple asignó un equipo para lanzar un entorno de ejecución de SK8, la limitación de las capacidades de Mac, así como el cambio al chip PowerPC, hicieron que un proyecto tan grande fuera intratable. Con la mayor parte de la visión original completada y sin un camino fácil para lanzarlo como parte de MacOS, el desarrollo activo finalizó en 1996-1997, y el código fuente de Macintosh Common Lisp para todo el proyecto se lanzó al público en 1997.
El proyecto SK8 fue creado por Ruben Kleiman cuando se unió a Apple en 1987. Había llegado a Apple para desarrollar una interfaz de usuario flexible y orientada a objetos y un entorno de desarrollo multimedia. [2] El nombre del proyecto deriva de su interés por el skateboarding . [3] Casualmente, en ese momento HyperCard , con su interfaz de manipulación directa y lenguaje de scripting, estaba a punto de lanzarse. Si bien HyperCard era excelente para aplicaciones simples, utilizaba un modelo de interacción limitado (las "pilas" de tarjetas) que limitaban su aplicabilidad potencial. SK8 intentó extender estos beneficios a un rol de programación más amplio. [2]
Los primeros trabajos sobre lo que se convertiría en SK8 se centraron en la infraestructura en lugar de en la programación visual. El primer esfuerzo de Kleiman fue un sistema de objetos dinámico basado en prototipos , MacFrames, un sistema de objetos / marcos con complementos para motores de inferencia. A través de la configuración de preferencias, MacFrames se utilizó para emular una gran variedad de sistemas de objetos, incluido KEE de IntelliCorp . Esta investigación, en conjunto con usuarios que desarrollaban aplicaciones y prototipos reales en Apple, produjo el modelo de objetos utilizado en SK8. [2] MacFrames se desarrolló en Coral Lisp, que fue adquirido por Apple y se convirtió en Macintosh Common Lisp .
En aquella época, Macintosh no tenía un sistema generalizado de comunicación entre procesos (IPC). Kleiman creó un IPC init para Mac que permitiera a MacFrames comunicarse con otros procesos, en particular, HyperCard. Esto permitió que HyperCard se utilizara como interfaz de programación visual para MacFrames. Otro objetivo de MacFrames era incorporar el procesamiento distribuido directamente en el sistema de objetos. En lugar de utilizar una API RPC, uno simplemente configuraba la propiedad del objeto con el valor deseado y devolvía la llamada para los resultados. El grupo de control de calidad de Apple utilizó MacFrames para crear un sistema automatizado de pruebas de caja negra.
El SK8 Project Builder fue creado para proporcionar un conjunto completo de herramientas de manipulación directa, incluidas herramientas para crear controles interactivos y pegado general pero no invasivo. [2] El objetivo del constructor era proporcionar una interfaz de manipulación visual/directa para crear entornos de desarrollo visuales. Es decir, el sistema podría usarse para desarrollar entornos de desarrollo completamente diferentes adaptados a diferentes tareas. La primera versión del sistema gráfico SK8 fue diseñada para ampliar HyperCard, lo que permite que las tarjetas tengan múltiples capas en lugar de una única plantilla de "fondo".
El sistema SK8 se programó inicialmente en Lisp, ya que se consideraba que era demasiado arcano para su uso general. Además, existía una creciente preocupación por la cantidad de lenguajes diferentes que se utilizaban en Apple. Como parte de un esfuerzo más amplio por modernizar MacOS, se deseaba un nuevo lenguaje de programación unificado. En 1989, Kleiman se unió a David Canfield Smith y Larry Tesler para diseñar e implementar la primera versión de AppleScript . Esta versión de AppleScript utilizaba objetos SK8 y, dos años más tarde, la División de Productos de Apple volvió a implementar AppleScript utilizando AppleEvents como el pegamento para comunicarse con los objetos AppleScript. El prototipo original pasó a llamarse SK8Script y, a su vez, se volvió a implementar en ensamblador en 1992.
Varios investigadores del Grupo de Tecnología Avanzada comenzaron a utilizar SK8 para sus proyectos. Algunas universidades y corporaciones también comenzaron a participar. [2] El sistema se utilizó para desarrollar prototipos para Newton , interfaces QuickTime, comunicación entre procesos y se utilizó para crear prototipos de muchos títulos, incluido Stagecraft, una herramienta de aprendizaje para niños.
Por razones de rendimiento, en 1992 y 1993 SK8 se volvió a implementar desde cero. En el Centro de Investigación de Cambridge de Apple, se aisló el almacén de objetos Common Lisp de Macintosh y se conectó directamente al almacén de SK8. El depurador SK8Script se volvió a implementar a nivel de lenguaje ensamblador (anteriormente en Lisp) y se mejoró el rendimiento del compilador y del tiempo de ejecución.
El sistema SK8 incluye el sistema de objetos, los objetos gráficos y de componentes, el lenguaje SK8Script y el entorno Project Builder.
El sistema de objetos SK8 estaba basado en prototipos , como JavaScript , pero a diferencia de JavaScript, las propiedades de los objetos eran en sí mismas objetos. 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); uno podría pensar en ellas como "propiedades inteligentes". La idea era permitir que los programadores de aplicaciones se centraran en manipular objetos en lugar de tener que aprender API, que se integrarían en los objetos. No se implementó un espacio de nombres jerárquico que administrara los nombres de las propiedades.
Hasta 1989, el lenguaje de programación de SK8 era Lisp. Luego pasó a ser SK8Script, que estaba muy influenciado por HyperTalk (HT). Muchas de las diferencias entre SK8Script y HyperTalk pueden considerarse como una generalización de los conceptos de HT, que elimina la integración estricta con objetos particulares del universo HyperCard y los reemplaza por una sintaxis generalizada que podría interactuar con cualquier objeto.
Al igual que HT, un concepto central del sistema SK8Script son los "contenedores", que en términos generales equivalen a objetos en los sistemas convencionales, y el sistema de "fragmentación" que permitía identificar y enumerar esos contenedores. HT había introducido la idea de ofrecer múltiples formas de abordar objetos y colecciones, lo que permitía al programador seleccionar la sintaxis que pareciera más natural en el contexto y luego usar una sintaxis completamente diferente en otro lugar. SK8Script ofrecía un sistema similar.
El universo de SK8 estaba formado por un sistema orientado a multimedia que utilizaba actores en un escenario. Los actores eran cualquier objeto basado en el prototipo de objeto Actor, que contenía el marco básico necesario para proporcionar soporte gráfico 2D (la ubicación y el tamaño del objeto, por ejemplo). Los actores se hacían visibles cuando se colocaban 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 como cualquier otro objeto gráfico. Cuando un actor estaba en el escenario, podía comportarse como un objeto similar a 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 contenido siendo un objeto de texto que se desplazaba o quizás una película que se reproducía dentro de su marco). Un objeto conocido como "halo" proporcionaba controladores de tamaño y otros widgets para su manipulación en un entorno de desarrollo visual. [5]
Todos los actores SK8 podrían contener otros actores. [6] La jerarquía podría navegarse usando las expresiones de fragmentación, por lo que uno podría set the visible of the first Rectangle in CoolOval to true. Luego, los objetos podrían hacerse visibles en la IU moviéndolos al escenario usando el insertcomando, como insert CoolOval into the stage, que haría que aparecieran tanto el óvalo como el rectángulo. [7]
Las GUI se construían únicamente a partir de actores. Un objeto similar a una ventana podía construirse 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 ayudaba al proceso de construcción de la GUI. Por ejemplo, el BevelRenderer podía usarse para biselar los bordes alrededor de un actor, produciendo un efecto como los controles de Windows 3.x o la barra de título en NeXTSTEP . Otros renderizadores incluían rellenos de color e imagen, degradados, mosaicos y mezclas. [9] Aunque no había diferencias en términos de programación, los objetos básicos como los rectángulos se clasificaban como "actores de geometría", 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 con el mouse y pulsaciones de teclas, y los enviaba a los actores. La jerarquía visual determinaba qué objeto recibiría el mensaje primero: el escenario estaba ordenado en Z y los objetos más cercanos al frente recibían los mensajes primero. Los mensajes podían pasarse a la jerarquía de clase/prototipo con el do inheritedcomando. [11]
Project Builder era un entorno para crear entornos de desarrollo visual. Proporcionaba edición de código, depuración, biblioteca de gráficos y componentes inteligentes, soporte para la selección de objetivos en tiempo de ejecución y un sistema de creación de interfaz gráfica 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 en ese momento. Estos incluyen bibliotecas, funciones y métodos creados por el usuario, variables, etc. [12] Estos se podían examinar y editar haciendo doble clic en ellos o haciendo clic en un menú emergente asociado que aparecía en el objeto cuando se seleccionaba en el generador de GUI. [8] El editor de objetos que aparecía enumeraba las "propiedades" del objeto ( variables de instancia y 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 "Stage" invisible que servía como fondo para gestionar eventos y objetos visuales. Un aspecto interesante era que no se necesitaban ventanas, en el sentido tradicional, ni se esperaba que mostraran 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). Sin embargo, SK8 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 de HyperCard era un editor de medios, que permitía mover recursos de Macintosh dentro y fuera del proyecto. SK8 incorporó esta funcionalidad al 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 y deshabilitar funciones del sistema operativo , lo que le permitía interactuar más directamente con Macintosh Toolbox . En HyperCard, la interacción con código arbitrario de Toolbox se manejaba a través de 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, con las operaciones internas invisibles. Con SK8, SK8Script podía interactuar directamente con el código encapsulado, estableciendo variables, llamando funciones y devolviendo resultados. El código externo también podía llamar a SK8Script, examinando y estableciendo variables o llamando funciones. [16]
{{cite book}}: Mantenimiento de CS1: falta la ubicación del editor ( enlace )