Si, por eso un camino a explorar es: - VM sobre .NET/Java/JavaScript
En esos casos, las librerias que se cargan YA estan escritos en un "underlying language" que tiene Garbage Collector y un sistema de tipos comun. No mas FFI, sino simple carga dinamica de modulos, librerias, require, etc... Y esas librerias que se cargan YA estan probadas en el "underlying VM". Y soportadas/probadas por parva de gente. Angel "MyLifeIsAVirtualMachine" Lopez ;-) 2012/11/14 Andres Valloud <[email protected]> > > siempre hay que tomar en cuenta unas cuantas cosas, obvio... pero a lo > que voy es que no vale la pena hacer una libreria de, ponele criptografía > (ya que german la menciona), sino que es mucho mas productivo usar una > libreria ya existente y ahorrarse de paso el costo de mantenerlo. > > A lo que voy es que hacer eso te expone al mundo de C, al cual en > general se le tiene un cierto rechazo en la comunidad Smalltalk, por > lo tanto se tiende a mirarlo asi no mas, y eso a la larga trae > problemas de fondo bastante serios. La clase de problemas se puede > describir en terminos de todo el undefined behavior que termina > ocurriendo en nuestros programas debido especificamente a asumir que, > como Smalltalk es simple, y como todo se puede hacer en Smalltalk, > entonces C hecho en Smalltalk se vuelve simple por clausura transitiva > (o algun asumido equivalente). Pero no es asi... simplemente compilar > una VM como corresponde ya es un requilombo. Y el tema de fondo de > los FFI es que hay un monton de casos que nunca podran cubrir bien > porque no son un compilador de C. Ejemplos hay a patadas. > > Andres. > > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > > http://www.clubSmalltalk.org > -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
