[View]  [Edit]  [Lock]  [References]  [Attachments]  [History]  [Home]  [Changes]  [Search]  [Help] 

Entrevista a Alejandro Reimondo (COCO8)

Alejandro Reimondo fundador de Smalltalking y creador de S8/U8 habla acerca de COCO8 [poner una breve intro de Ale y su rol en U8/S8]

Version 2


1.1) Podrías contarnos un poco lo que hay en la contribución COCO8 y cómo funciona.
La contribucion contiene los fuentes de la aplicacion coco8, una aplicacion para iOS, "market compatible" y en constante desarrollo.
Los fuentes incluyen todo lo necesario para armar la aplicacion y es util como punto de partida para quienes desarrollan para iOS y OSX usando S8 Smalltalk.

Could you talk about what is in the COCO8 contribution and how it works.
The contribution contains the COCO8 sources application, an application for iOS "compatible market" in active development.
The sources includes everything needed to build the application and is useful as a starting point for developers for iOS and OSX using Smalltalk S8.

1.2) Con todo el furor de desarrollos HTML5 y todo lo que hay hecho, por qué volver a lo nativo?
No es volver, es sumar.
Desde Smalltalking siempre alentamos el uso de TO (con Smalltalk) en ambitos diversos, sin fronteras. Con S8 tenemos un soporte de ejecución para una gran variedad de hardware y sistemas operativos; el desarrollo de aplicaciones nativas no es limite para usar S8. Quien necesite sacarle provecho a esta forma de ejecutar sus objetos, tiene en S8 un smalltalk moderno, con que trabajar y expandir sus posibilidades de ejecución/negocios/etc.

With all activity in HTML5 developments and all that is done, why go back to native?
It is no "go back", it is a matter of adding.
From Smalltalking always encourage the use of TO (Smalltalk) in diverse areas, without borders. With S8 we have a runtime support for a variety of hardware and operating systems; the development of native applications is not a limit to use S8. Who needs to take advantage of this way of running their objects, can use S8 (a modern smalltalk) to work and expand their possibilities of execution/ business/etc.

1.3)Para usar COCO8 es necesario implementar algo en Objective-C o se puede desarrollar integramente en S8?
El 100% de la aplicación puede ser implementada en S8 Smalltalk. En el caso de tener desarrolladas algunas partes en ObjectiveC y/o javascript
(por ejemplo, librerías, etc) uno las puede usar a bajo costo escribiendo la interfaz TOTALMENTE en S8 smalltalk.
El sistema (smalltalk) puede arrancar con un contenido minimo, y luego cargar dinamicamente (bajo demanda) contenidos y comportamiento desde recursos externos(memoria, internet, bases de datos, etc).
Coco8 además funciona como servidor e implementa servicios de upload (al telefono), por lo que la totalidad del sistema puede modificarse subiendo contenido al telefono mismo, los que pueden accederse al instante por coco8 o en el proximo arranque (por ejemplo, el image del sistema y recursos pueden subirse a coco8 en el telefono/tablet y arrancar con un comportamiento totalmente distinto del original).
El sistema original de coco8 puede modificarse (contiene un set de herramientas U8) y grabar el image, de forma tal que en la proxima ejecución arranque considerando ese nuevo image.
Como en todo smalltalk, las herramientas (workspace, browsers, referencias, app/module loaders) estan totalmente escritas en S8 Smalltalk, siendo de un inmenso valor didactico.

To use COCO8 is it necessary to implement something in Objective-C or can be entirely developed in S8?
100% of the application can be implemented in Smalltalk S8. In case of developed parts in ObjectiveC and / or javascript
(Eg, libraries, etc), you can use them at low cost building an interface FULLY written in S8 smalltalk.
The system (smalltalk) may starts with a minimum content, and then load dynamically (on demand) content and behavior from external resources (memory, internet, databases, etc).
COCO8 also works as a server and implements upload services (on the phone), so that entire system can be modified uploading content on the phone, which can be accessed instantly by COCO8 or next boot time (for example, the system image and resources can be uploaded to COCO8 on the phone/tablet and start with a completely different behavior from the original).
The COCO8 original system can be modified (it contains a set of U8 tools) and record the image, so that in next execution starts considering this new image.
As in any smalltalk, tools (workspace, browsers, references, app / module loaders) are completely written in Smalltalk S8, being of immense didactic value.

1.4) Desde S8 podemos acceder a javascript. Es posible ver las clases que están del lado de Objective-C, como funciona?
Si todas las clases de ObjectiveC que esten en el sistema se pueden usar (recomendable que sea mediante wrappers c/ API builders[]) y ademas se pueden
subclasificar (crear subclases totalmente implementadas en S8). Se puede acceder a los niveles: javascript, en forma completa a todas las librerias que
puede el sistema tener y/o cargar dinamicamente. Objective-C se puede acceder via wrappers c/API builders y de forma inline -usando sintaxis extendida de S8-. C, se puede acceder a funciones y estructuras implementadas en C de forma dinamica.
[] los API builders son parte del framework de NativeObject, un framework muy poderoso y unico de S8, que permite acceder a todos los niveles inferiores de forma simple y reduciendo eficientemente el margen de errores humanos.
En resumen, escribiendo todo en S8 Smalltalk uno puede acceder a todo elemento del sistema y puede cambiarlo/subclasificarlo/refinarlo dónde está permitido
hacerlo por Apple.

From S8 we can access to javascript. Is it posible to see classes that are on Objective-C side, how it works?
Yes, all Objective-C classes that are in the system can be used (recommended use it via wrappers with API builders []) and also can be
subclassed (create fully implemented subclasses in S8). You can access levels: javascript, in a full way to all the libraries the system may have and/or load dynamically. Objective-C is accessible via wrappers with API builders and also inline, using S8 extended syntax. C, you can access functions and structures implemented in C in dynamic way.
[] The API builders are part of the framework of NativeObject, a powerful and unique framework of S8, which allows access to all lower levels simply and efficiently reducing the margin for human error.

In short, writing everything in Smalltalk S8 you can access any element of the system and you can change it/subclass it/refine it where is allowed by Apple do it.

1.5) Esto quiere decir que con COCO8 se puede subclasificar un elemento gráfico como por ejemplo un panel de texto? O definir un widget nuevo? La ejecucion es en S8 y en Objetive-C?
Si, cualquier clase; sea grafica como de cualquier framework y/o libreria que esté presente en el sistema y accesible en ObjectiveC (y/o C). El ejemplo de Polygon en coco8 es justamente eso. Un panel grafico implementado integramente en S8; tanto en el dibujado como en el manejo de la interaccion por touch. Todo lo estatico en el sistema esta relacionado con Objective-C (Apple no permite generar metodos/funciones dinámicamente en ObjectiveC). Todo lo dinamico y abierto del sistema es S8 Smalltalk. En consonancia con el diseño e historia, tanto de Objective-C como de Smalltalk.

This means with COCO8 a graphic element, such as a text panel, can be subclassified? Or can be defined a new widget? Is the execution is in S8 and Objective-C?
Yes, any class; any graphic class or any framework class and/or library that is present in the system and Objective-C accessible (and/or C). The example of Polygon in COCO8 is just that. A graphic panel implemented entirely in S8, both drawing operations and touch interaction handling. All static in the system is related to Objective-C (Apple does not allow generating methods/functions dynamically in ObjectiveC). Everything dynamic and open in the system is S8 Smalltalk. In line with the design and history of both Objective-C and Smalltalk.

1.6) Hay alguna consideracion especial en usar COCO8 en iOS o en OSX? El desarrollo sobre COCO8 es igual en las dos plataformas?
Ambas plataformas tienen una interfaz identica al sistema operativo. Las diferencias son diferencias entre los sistemas operativos y librerias que estén ejecutando.
En COCO8 ss exactamente el mismo esquema de desarrollo.
La API de Apple para una y otra plataforma es lo que determina las diferencias e incapacidad de usar el mismo codigo (los mismos objetos);
en muchos casos los mensajes y nombres de clases son similares pero con semánticas distintas; lo que hace recomendable mantener desacoplado el sistema de las dependencias de base; por la incapacidad de reusarlas y porque además (y mas importante) el alto nivel de obsolescencia prematura que sufren las
interfaces en estos S.O. (comparado con lo que se produce frecuentemente con smalltalk). Las interfaces UI, por lo gral. cambian antes de que sean usadas mucho tiempo. Es un caso frecuente (en todo lo formulado como OO) que las cosas se "digan viejas" cuando aun no llegan a tener cinco años... y como... para ser experto en cualquier área, una persona requiere de al menos 10 años de dedicación efectiva, se dá que las UIs (y otras cosas como los lenguajes) solo llegan a los anuncios y tener el beneficio de la propaganda como instrumentos de propagación en quienes necesitan de algo nuevo.
En el caso de smalltalk, la UI (y la forma de hacerla) prevalece por décadas y no ha sido muy frecuente la presión de gente que utiliza el propagandismo para inyectar la idea de cambios efímeros (son pocos los modos de construcción de UI que han sido propuestos; algunos violando los principios básicos del trabajo con objetos... pero bue, ese es otro tema). Para aquellos que se sientan interesados en estos temas no dejen de consultarnos a través de nuestra lista de discusión.

Are there are some special consideration in using COCO8 in iOS or OSX? The development in COCO8 is the same on both platforms?
Both platforms have an identical interface to the operating system. The differences are differences between the operating systems and libraries that are running.
In COCO8 ss exactly the same pattern of development.
The Apple API for each platform is what determines the differences and the inability to use the same code (the same objects);
in many cases messages and class names are similar but with different semantic; is advisable to keep decoupled base system dependencies because the inability to reuse them and also because (and more important) the high level of premature obsolescence faced by these interfaces in these S.O. (compared to what often occurs with smalltalk). The UI interfaces, usually change before they are used long. It is often the case (like everything formulated as OO) that things will "say old" when even get to not have five years ... and to be expert in any area, a person requires at least 10 years of dedication effective, is given that the UIs (and other things like languages) only reach advertisements and have the benefit of propaganda as instruments propagation for those who needs something new. For smalltalk, UI (and how to do it) prevails for decades and has not been very frequent pressure from people who use the propagandism to inject the idea of temporary changes (there are few ways to build UI which have proposed, some violate the basic principles of working with objects ... but that's another topic). For those who feel interested in these topics do not hesitate to contact us through our discussion list.

1.7) Cuales serian los pasos minimos para arrancar un proyecto COCO8?
Como en todas las modalidades de trabajo con S8, lo recomendable para empezar es utilizar el vinculo social (social software development with smalltalk) y hacer lo que uno hace siempre (doIt yourself w/smalltalk)
1.-Leer las paginas del swiki de U8 relacionadas con coco8 http://swiki.smalltalking.net/U8/Coco8Index
2.-anotarse en la lista de testers y registrar los dispositivos iOS dónde pueda bajar coco8 y ejecutarlo
3.-Ponerse en contacto con gente que lo esta usando, preguntar y empezar a desarrollar lo necesario.

What would be the minimum steps to start a COCO8 project?
As in all modes with S8, it is advisable to start using the social link (social software development with smalltalk) and do what you always do (doIt yourself with Smalltalk)
1.- Read pages of U8 Swiki related to COCO8
2.- Register in testers list and register devices iOS where you can download and run COCO8
3.- Contact people who are using, ask and start developing what you need.

1.8) Por que el nombre COCO8?
En iOS y OSX los framework de base propuesto por Apple se llaman Cocoa, el 8 es por lo mismo que en S8 (denomina la actividad de construccion de experiencia que utilizamos -smalltalk-).-

Why the name COCO8?
In iOS and OSX the basic framework proposed by Apple called Cocoa, 8 is the same as in S8 (called the activity of construction experience we use -smalltalk -) .-



Version 1


Podrías contarnos un poco lo que hay en la contribución COCO8 y cómo funciona. Vos estas creando clases de Objective-C dinámicamente, puede ser?
Puedo comentar cómo es la plataforma y lo que había hasta el momento. Tambien me gustaria comentar el motivante para hacerlo.
La plataforma que tenemos, la que sería Cva8, permite desarrollar de manera compatible. Compatible me refiero a todo lo que uno escribe en Smalltalk corre dentro de un WebView en un Android, en un iPhone o en un iPad. Cualquier elemento que uno quiera usar y sea nativo se tiene que conectar por medio de un plugin. Toda la plataforma de Cordova está definida con plugins y eso resulta muy cómodo para las aplicaciones normales. Por ejemplo: si uno quiere hacer una aplicación que esta accediendo a datos locales, que este viendo si esta la conexión wifi abierta, que este bajando datos directamente de un servidor, etc. Todas esas cosas ya Cordova viene con plugins y tiene especificadas las API’s donde uno por medio del framework Cva8 directamente desde S8 Smalltalk accedemos a toda esa API que es bastante extensa y está muy buena. Así uno puede hacer aplicaciones que corren dentro de una WebView, es decir aplicaciones que son HTML5 mas accesos nativos dados por Cordova o por alguna extensión que uno haga haciendo plugins nuevos. Ahí es donde está la parte extensible de Cordova que está buena, porque uno hace el plugin y después la conexión con el plugin se conecta directamente desde Smalltalk. Es decir, en Cordova te proponen que uno tenga que escribir en un archivo aparte en Javascript, pero en el framework Cva8 ya implemente absolutamente todo lo que uno tiene que hacer para conectarse con un plugin nativo y lo hace directamente desde S8.

En Cordova el plugin debe ser escrito en bajo nivel?
El plugin debe ser desarrollado con el tool de cada plataforma. Es decir, se debe implementar el plugin en cada plataforma que va a ejecutar. Entonces debería implementarse en iOS y en Android.

La conexión en javascript es algo engorroso?
No, no es engorroso la conexión desde el lado de javascript, y agregaría que, menos desde el lado de Smalltalk. Lo que se torna engorroso es escribir del lado nativo. Porque las dos plataformas iOS y Android son distintas. Y porque principalmente el plugin no necesariamente corre en el mismo espacio de ejecución, en el mismo thread, que el WebView. Entonces esto complica la escritura del plugin.
Una complicación es que en algo que es nativo se pregunta algo y el valor vuelve inmediatamente. Pasar por el plugin del lado de javascript, hace que no llegue en la misma operación. Es decir, hay que hacer como si fuera un callback. Un bloque que se va a activar cuando el plugin logre obtener el valor. Entonces eso empieza a complicar todo el modelo de programación. Porque va a un modelo asincrónico.

Seria posible integrar el mecanismo de generators que permite escribir de manera secuencial sin complicar el fuente, o lo lineal del fuente. Tiene solamente esas implicancias o también además hay un tema de performance?
No, en una plataforma puede ser de una manera y en la otra de otra. La verdadera razón es porque la forma más compatible, es que sea esa. Entonces desde arriba siempre se espera de forma diferida el resultado. Y después la implementación nativa puede encolar el resultado antes o después, No, en una plataforma puede ser de una manera y en la otra de otra. La verdadera razón es porque la forma más compatible, es que sea esa. Entonces desde arriba uno siempre espera de forma diferida el resultado. Y después la implementación nativa puede encolar el resultado antes o después, pero el tema es que son cosas puntuales las que puede devolver inmediatamente el valor. Solo son cosas puntuales las que puede devolver inmediatamente el valor.

Cuando se adquieren datos del teclado?
Ese un buen ejemplo en donde no puede ser instantáneo. Todo el diseño del plugin de Cordova está planeado para que cuando uno pide algo viene en un callback y eso genera problemas en varias cosas. Este es una de los motivantes, que no es algo que moleste demasiado, pero si es un factor de incomodidad cuando uno desarrolla. Al menos cuando uno desarrolla en Smalltalk uno esta más acostumbrado trabajar más imperativamente.

Eso es similar en NodeJS
Si seguro, es un modo de trabajo que es muy costoso porque fracciona el sistema. Por otro lado no es el único problema que puedo ver en Cordova. Digo, no es el mayor problema. El mayor problema es que la aplicación queda dentro de una WebView. Y qué implicancias tiene eso? Uno podria decir: “bueno vos pones todo dentro de una ventana si después lo que dibujas adentro se puede ver igual”. Yo hice una aplicación con Cordova en donde el look es el de iPhone, después se trabajo un poco en tratar de minimizar el tiempo que llevaría cambiar de look y demás, entonces uno podría pensar en usar HTML5 para renderizar la interfaz y hacer un skin que sea igual a cada una de las plataformas y listo. Pero eso no termina viéndose/sintiéndose nativo. Porque en los teléfonos por ejemplo en iOS, en los modelo nuevos sobre todo, el usuario está acostumbrado que las cosas se muevan en interfaz. Que se mueva toda la ventana. En Android ya se está empezando a ver exactamente lo mismo. Y eso invalida la idea de tengo todo en una WebView, porque nunca vas a tener la performance que tenes cuando lo haces nativo.
Si uno dice: “bueno puedo programar para todas las plataformas” pero después no se puede ver igual que en ninguna, estamos como cuando decíamos: “bueno trabajamos en Smalltalk y nuestras pantallas son de color pastel y muy lindas pero no se ve igual que en ningún sistema operativo! Eh? Naces con un look con un jopo de viejo terrible!! (risas).
Si yo te digo el look lo hago similar, no esta resuelta la parte del feel. Y es muy importante. Eso desde el punto de vista del usuario es importante. Estamos haciendo un gran esfuerzo para después vernos “viejos” o como un “bicho raro”, que se note diferencias porque uno lo hizo. Me parece mucho esfuerzo para obtener insatisfacciones después. Y el tercer punto (me cuesta ordenar en importancia, hasta ahora los dos que nombre me parecen muy importante) El tercer punto, también me parece muy importante, no sé si más o menos que los dos anteriores y es el siguiente: estuve trabajando bastante tiempo en escribir plugins que sean widgets nativos y usar Cordova para instanciar y para setear y para tener los eventos de esos elementos nativos. Es decir, hice la experiencia de trabajar con Cordova y una WebView pero minimizo la WebView o la pongo en otro lado y creo widgets nativos y desde Smalltalk accedo a esos elementos nativos vía un plugin. Entonces ahí me encuentro con el tema del callback, pero si eso termina siendo conveniente tengo un look & feel. Tengo lo que busco.
Me resulto muy costoso desarrollar los plugins, pero creo que fue una buena experiencia que logre hacer para las dos plataformas. No con muchos elementos pero si lo suficiente para lo que quería evaluar. E hice una valoración de qué era lo que me quedo. Y qué encontré? Que en realidad es muy importante la energía que uno pone en la parte de los plugins. Para escribir algo que funciona igual en iOS con el tool de XCode5, con lo mejor que tiene la plataforma iOS, para escribir el plugin, configurar todo y demás, que eso lo tenes que hacer si o si trabajando con Cordova. La documentación que hay sobre los plugins es bastante escueta, entonces la implementación no es algo que lo hace cualquiera, me imagino, pero lleva bastante tiempo hacerlo y testearlo. Con Android exactamente lo mismo, es un poco más precario la forma de hacerlo, en lo que respecta a como uno escribe el código, el tool es el eclipse entonces es equivalente al XCode y el esfuerzo de escribir los plugins es equivalente. Y en los dos casos, es mucho mayor que si uno estuviera trabajando en Smalltalk. Esto me parece muy importante porque el costo de mantenimiento (un costo que se multiplica por cada plataforma que uno transite) del plugin implica mantener los tools todo el seteo. Por ejemplo sucedió que actualizaron XCode y dejo de funcionar y la gente de Cordova decía que en la próxima versión lo iban a tener resuelto y la gente decía: “pero como?, la otra versión la tienen planificada para el otro año!”.O sea dejo de funcionar Cordova para XCode5 que es la última versión para Apple y se va a actualizar cuando hagan el próximo release. Mientras hay que compilar con una versión de XCode anterior que no es la ultima de Apple. Son los costos que tiene la manutención de un sistema que está escrito en más de un tool.

Cual sería un caso concreto de un plugin
El widget de la fecha, el calendario que es como un tamborcito que corre la fecha. En iPhone es algo que toda la gente lo identifica como de iPhone, las aplicaciones usan eso. Android tiene una forma un poquito más elegante pero también es nativa. Y en la plataforma web, al día de hoy, no hay nada decoroso. Si lo hacemos con HTML5 hay que hacer un control custom que vos haces en HTML5 y no andar con una rueda con toda una animación que no la podes lograr igual con HTML5, o lo vas a lograr al costo de rehacer la rueda. Ese me parece que es un buen ejemplo de un control que tiene que ser nativo. Yo estoy seguro que la WebView de Android muy pronto ya lo va a traer cuando vos pongas un campo fecha en un formulario. Pero al día de hoy y hace 4 meses no estaba. Entonces es un candidato que uno tendría como un plugin y de hecho hay tres o cuatro proyectos de plugins para Cordova, ninguno igual, y algunos son para iOS y otros para Android. Tenes toda esta problemática, si tenes que usar un plugin, te lo vas a hacer vos, porque si vas a tomar de uno o de otro no te andan para todas las plataformas. Porque cada uno hace para los equipos que tiene. Entonces este es un buen ejemplo para ver que ir vía un plugin y hacer un plugin nativo es una frazada muy corta. Pensando en ese problema me costó mucho decir bueno dejo de lado lo del WebView porque la comodidad de trabajar con HTML5 y todo lo que tenemos estaba dentro de una WebView te tienta a decir: “eso no lo podes sacar ni loco”. Entonces empecé a buscar, primero tratando de hacer andar V8 en forma nativa en iOS y encontré un proyecto que se llama jsCOCOA>http://inexdo.com/JSCocoa que es la base de lo que estoy usando ahora. Y es interesante lo que hacen. Levantan la VM de javascript de Apple, que es la que usa el WebView de Apple, y cargan un framework que integra esa VM de javascript con la librería de FFI, de llamadas a API, y desde esa manera desde javascript tenes una interfaz a C y Objective-C. Esta muy bueno eso…

Esta librería de FFI funciona en Android?
Hay una versión para Android pero todavía no la pude hacer andar. No sé si anda o no en la última versión, pero cuando la probé no andaba. Estaba en desarrollo todavía. Pero para iOS me encontré con un precedente, esta gente habia trabajado bastante sobre la parte de javascript es decir, había una parte que no me servía, hacían las cosas más complejas de lo que necesitaba. Pero tenía ahí una base, y no andaba en el teléfono de verdad. Andaba en el simulador. Y no andaba porque una de las parte en assembler que tenía en FFI no andaba en el teléfono y empecé a buscar en otros proyectos. Y encontré dos o tres proyectos de FFI para iPhone y ninguno de esos andaba en el telefono. Es decir por diferentes ensambladores por diferentes versiones de XCode no había caso. Entonces volví al (… aca se corto el audio y no sé que dijo Ale. Y continúa con lo siguiente) … de iPhone y iPad que hay ahora. Los puse, los “debuguié” y saque andando FFI en el iPhone y en el iPad y lo integre, es decir saque una versión más nueva, con lo de estos tipos entonces tuve andando las partes que quería. Es decir, podía instanciar la maquina virtual, cargar un image de S8-U8 y acceder a las clases de Objective-C, y la parte que ellos tenia de generación de clases que ellos ya estaban haciendo me sirvió.
Entonces con esto escribí una aplicación una de las demos que ellos tenían que es de una estrellita, es un widget grafico nativo como si fuera el GraphPane que dibuja una estrella, mas un control que le cambia la cantidad de lados que tiene la estrella (acá se entrecorta de nuevo …) luz y sombra, maneja drag & drop sobre ese elemento visual y va girando la estrella con drag & drop, o va cambiando de forma. Es una demo bastante simple, pero fue mi mayor motivante para meterme por ese camino porque vi la posibilidad de que uno puede hacer un panel grafico con cualquier dibujo, con cualquier cosa y manejar los eventos y generar los cambios dinámicamente en toda la grafica en tiempo real.
Implemente las partes de bajo nivel en S8 Smalltalk, sacando toda la parte de javascript. Es decir me quede con lo que era útil quedando escrito en S8. No necesitaba más nada, ni de ninguna incorporación de nada en javascript.
Al final lo que tenemos es una aplicación XCode que lo único que hace es levanta el engine de javascript y carga un image nuestro, y ese image cuando carga, arranca el image de la aplicación. Luego la aplicación esta escrita totalmente en S8 Smalltalk. Esto se logra porque tenemos un mecanismo de reflexión.
En Objective-C la clase equivalente a Object de Smalltalk se llama NSObject, yo lo que hice en S8 implementar una clase que se llama ObjectiveCImplementation y la única subclase, en teoría, de esa clase es NSObject. Se llama igual a la de Objective-C. De ahí para abajo uno agrega subclases con nombres de clases que pueden estar en Objective-C , o no, en el runtime de Objective-C. Es decir, cuando carga nuestra imagen de S8, lo que va a hacer luego de cargar, es ir a esa clase ObjectiveCImplementation y para todas las subclases de Smalltalk se fija si esa clase está actualmente corriendo en Objective-C. Si esta, no hace nada en el startup del sistema; y la clase se usa como un wrapper de la existente en Objective-C (runtime). Si no está, crea una clase del lado de Objective-C (S8) que se llama igual y le instala algo que uno pone en un literal que lo implementa en un método de la clase, que es la interface que uno le pone a esa clase. Entonces se instancia una clase del lado de Objective-C (S8) y con esa interface, se agarran los métodos que estén implementados del lado de instancia en Smalltalk, que uno definió en esa interface, y se instala del lado de Objective-C como wrappers de métodos, véanlo un poco así. Es decir, se instalan métodos de Objective-C, que cuando son llamados llaman a javascript, activando el método smalltalk.

Y cómo es posible ver las clases que están del lado de Objective-C?
Hay una capa de reflection para eso. Uno puede ver si existe una clase con un determinado nombre, esa clase que métodos implementa, se puede instalar un método en esa clase, pero no cualquier método, sino que tiene que ser un método que ya tengas instalado del lado de la clase de Smalltalk e implementado como un método de la instancia.

Entonces en un primer momento se construye una jerarquia paralela (en S8) a la existente en Objective-C.
No. Tu aplicación tiene un image y de las clases que hereden de NSObject (del lado de Smalltalk) se recorren todas las subclases y se ven si no están implementadas en Objective-C, las que no estén implementadas, se implementan como clases que cuyos métodos están del lado de S8. Es decir, se arranca con un sistema que es el que tiene los frameworks de base de Objective-C y después carga un conjunto de clases del lado de S8 que si no llegan a estar en Objective-C, se implementan, entonces es como que se prende todo tu sistema Smalltalk al runtime de Objective-C cuando el sistema arranca.

Esas clases que no están del lado de Objective-C, son clases de tu aplicación?
De cualquier cosa, y ahí es donde viene la parte interesante…si esta debajo de NSObject lo va a implementar.Por ejemplo: las ventanas, los archivos, las librerías de acceso a file system, sockets, widgets, todo iOS esta imeplementado debajo de NSObject. Hay algunas excepciones porque también tienen proxys y demás, pero para lo que estamos hablando ahora, sue puede implementar una clase que cuelga de cualquier clase de Objective-C. Entonces se puede subclasificar, por ejemplo, TextView. Se puede subcliasificar cualquier panel, o subclasificar un file un directory.

Y esa subclase es una subclase de S8…
...es una subclase que se implementa en S8 y en un método que se pone como si fuera un método primitivo, arriba como una directiva dice: “este es un Objective-C method”. Que es completamente en Smalltalk y si se quiere, o se necesita, se puede decir: “super tal cosa” y se va a hacer el super en Objective-C.
Imaginemos que vamos a hacer una subclase de un TextPane. Uno implementa unTextPane que hace en uno de los métodos algo antes y hace “super tal cosa” y entonces eso va a la implementación de Objective-C del panel original. En ese caso, lo que se hace es definir una subclase de ese panel de texto, que es nueva, y ahí dice el método “tal” que está en al API del panel de texto, yo lo voy a sobre-escribir, uno pone el mismo nombre de mensaje y los mimos argumentos, para que luego cuando al objeto ese cualquier parte de Objective-C envie ese mensaje, viene a javascript y se activa el método S8, y en ese método uno hace lo que se desee y luego se envia super para que vaya al método nativo de la superclase en Objective-C. Entonces esto permite innovar en métodos que son de base de Objective-C. Ahora qué pasaría con un método que se implemento en Smalltalk de la misma clase y es interno de tu implementación. No es necesario llevar ese método a Objective-C, porque ahí no conviene andar saltando a Objective-C, a mitad de camino. Entonces esos métodos no se ponen en la interface de la clase tuya, la que se va a replicar del otro lado, se ponen nada más que en los métodos que son, de alguna manera subimplementaciones, entonces esa parte corre toda en S8. Y los mensajes que se llamen o que suban y activan métodos que son de S8 (de Object de S8) y demás, eso la ejecución es toda en javascript, y va a ir al espacio de Objective-C en la situación que se haga un “super” o que se envíe un mensaje a un objeto que está del otro lado. Del lado de Objective-C, y ahí, ocurre el camino inverso, del lado que no es nuestro se hace la llamada a un método, se transforman los argumentos, para que vaya a Objective-C y se active Objective-C y devuelve. La ventaja que tiene todo esto es que el resultado vuelve instantáneamente. Entonces, uno puede acceder a cualquier cosa que sea nativa. Uno puede subclasificar lo que está en nativo escribiéndolo en Smalltalk, sin perder nada de la forma de trabajo de Smalltalk y de envio de mensajes instantaneo. Salvo en las cosas que que son ya por naturaleza diferida. Por ej: buscar algo a la web y cuando vuelva se va a tener por medio de un mecanismo diferido el resultado, pero todo lo que tenga que ver con llamadas a la API o llamadas al framework de base se accede con muy buena performance y se tiene un objeto que va a venir de manera directa, o te va a venir un proxy de Objective-C al cual se le va a poder enviar mensajes como si tuvieras el objeto en Smalltalk. Entonces la forma de programar una aplicación es muy transparente y se puede usar cualquier parte del framework del iOS e incluso subclasificarlo y crear instancias de las subclases, enviarlas en llamadas API donde estas enviando una instancia de una subclase, todo eso funciona perfecto.