Sì, en realidad no se entiende. Me disculpo. En traits no trabajas usando herencia, sino usando composiciòn. Mientras en la herencia redefines lo que no te gusta de la superclase, en traits no hay un mecanismo claro o ùnico de resoluciòn, lo cual es malo y bueno al mismo tiempo.
Es malo porque el programador que trabaja con traits tiene que averiguar o inventar cuàl es el mecanismo de resoluciòn de conflictos si hay un mètodo repetido. Por ejemplo, que es sistema levante una excepciòn. Otra alternativa es que el sistema use la primera clase que se le pase como paràmetro, luego la segunda, etc. ¿Porquè no? Al menos es una mecanismo de resolución. Sin embargo los programadores se revelan cuando necesitan el primer mètodo de esta, el segundo de esta otra, etc. porque finalmente el mecanismo de resoluciòn les da poco control y se vuelve inùtil. Por ejemplo podrìa diseñarse un mecanismo de override en que se asocie el nombre de un mètodo con el nombre del trait que lo resuelve (si al fin y al cabo los traits son clases y las clases tanto en Smalltalk como en Java son elementos de primer orden -first class objects-). Es fàcil de imaginar y dirìa que hasta fàcil de implementar. Ahora bien, dado esto, ¿què importancia tiene esto para los traits? Con esto me refiero a que no veo ninguna razòn para que Smalltalk no pudiera ser completamente reimplementado con Traits en vez de herencia. De hecho hace unos 2 años hicimos un sistema en Java sin EJB, pero con un EJB proxy. Usaba Struts, pero con una sola pàgina (y Struts a su vez utiliza un ùnico servlet). El sistema volaba, era rapidìsimo aunque no hicimos ninguna optimizaciòn en ninguna parte, es sòlo porque utilziaba pocos recursos. 400 pantallas y creo que nunca he visto un sistema tan ràpido. En parte supongo que se debe a que Java ahora es màs ràpido que C y pronto serà tan ràpido como Fortran. Pero tambièn he visto tanto sistema hecho en Java que es lentìsimo. Claramente los tipos que construyen sistemas hoy en dìa estàn usando conceptos de hace 40 años, cuando un programa de 4K usaba toda la memoria disponible y por lo tanto la optimizaciòn era al bit. Ahora tienes 2 GB de RAM y 300 tablas en una base de datos, de modo que las optimizaciones que realizan como "precompilar todas las pàginas" lo ùnico que logran es que los 400 JSPs usen mucho màs memoria que si no estuvieran compilados. Ahora piènsenlo desde el punto de vista de las clases, si tnego 400 clases precompiladas (y en Java esto se peude llevar al nivel de bits usango GJC o como se llame el GNU Java Compiler) usa al final un montòn de memoria en vez de usar GIT). En ese sentido Smalltalk se adelantò por lo menos unos 10 años cuando inventò el compilador de bytecode a còdigo de màquina para el còdigo mas hot. Esto lo discutìa con un profe de la U, pero èl insistìa en que era màs ràpido si todo estaba compilado. Obviamente èl estaba equivocado porque todas las pruebas demuestran lo contrario, el ùnico problema que tengo con esto es que la mayor parte de los ingenieros que van a la U se quedan con lo que dice el profe en vez de hacer pruebas por ellos mismos. Para mi gusto esos no son ingenieros, de la misma manera que alguien que estudia mùsica pero no canta ni toca un instrumento no es un mùsico. Saludos, Guillermo. 2008/9/13 Andres Valloud <[EMAIL PROTECTED]> > > No se, solo estas de acuerdo con algo que escribi que empieza asi: > > "Pero con Traits..." > > Si ahora no se entiende que tiene que ver con Traits, no se que mas > decir. Se me hace dificil seguir la conversacion. > > Andres. > > > 2008/9/13 Guillermo Schwarz <[EMAIL PROTECTED]>: > > Estoy super de acuerdo contigo. > > > > Pero ¿qué tiene que ver esot con los traits? > > > > 2008/9/12 Andres Valloud <[EMAIL PROTECTED]> > >> > >> Pero con Traits no tenes todas las ventajas de la herencia porque > >> (hasta donde me acuerdo) no podes tener traits que tengan colisiones > >> de mensajes, con lo que no es posible replicar lo que se hace con > >> herencia... por ejemplo reimplementar un metodo de la superclase... > >> como por ejemplo, en un caso extremo, > >> > >> aMessage > >> > >> super somethingElse > >> > >> > >> que a veces es muy util. > >> > >> Andres. > >> > >> > >> 2008/9/12 Guillermo Schwarz <[EMAIL PROTECTED]>: > >> > > >> > > >> > 2008/9/12 GallegO <[EMAIL PROTECTED]> > >> >> > >> >> Guillermo Schwarz escribió: > >> >> > > >> >> > ok, pero ¿tiene base lo que dices? > >> >> > > >> >> > Por ejemplo, ¿leìste el paper de Snyder de 1986 (22 años atràs) que > >> >> > lo > >> >> > indica y explica en detalle?: > >> >> > http://www-plan.cs.colorado.edu/diwan/class-papers/snyder.pdf > >> >> Perdon. Pido perdon por no haber leido ese paper, me baso solamente > en > >> >> mi experiencia. > >> >> ¿Pero, quién es ese tipo? Busque así nomas referencias en Internet y > no > >> >> encontré nada. Bueno, si vale la pena saber quien es me gustaría > alguna > >> >> referencia. > >> >> Por ejemplo, puede ser que yo tenga la misma base que ese Snyder > >> >> jajaja, > >> >> aunque no creo porque él publica papers! > >> >> Aparte, no estoy de acuerdo con lo que dice ese documento. Como decía > >> >> Andrés Vallould: protegerse. Porque arranca con el tema que > charlabamos > >> >> y termina pidiendo mecanismos para restringir el acceso a variables > de > >> >> instancia definidas en las superclases. > >> > > >> > > >> > Creo que ese es un grave error de Smalltalk, permitir el acceso a las > >> > variables de instancia de las superclases. > >> > > >> > Como decían de C++: "In C++ only friends can access your private > parts" > >> > de > >> > http://www.softpanorama.org/Lang/Cpp_rama/humor.shtml > >> > > >> >> > >> >> > > >> >> > Creo que estamos hablando de lo mismo, pero por alguna razòn haces > >> >> > una > >> >> > distinciòn irrelevante. El hecho de que en Smalltalk el sistema > estè > >> >> > ejecutando mientras programas, creo, es totalmente irrelevante. > >> >> > > >> >> > > >> >> Puede ser desde el punto de vista técnico. Para mi la herencia es una > >> >> herramienta más del sistema que me ayuda a desarrollar y por lo tanto > >> >> no > >> >> tiene que ver con los objetos, quizás se me hace difícil explicarlo > >> >> correctamente. No se si existe una similitud con la forma de > >> >> desarrollar > >> >> en Self en esto que digo ¿es asi? > >> > > >> > > >> > El asunto está en que herramienta o no, la herencia tiene un proósito > >> > que es > >> > no repetir código, lo cuál supongo que estamos todos de acuerdo en que > >> > es > >> > algo loable, probablemente con la excepción de los programadores en VB > y > >> > en > >> > SQL. > >> > > >> > Por otro lado la encapsulación permite mantener los invariantes de > modo > >> > que > >> > también es loable. > >> > > >> > Luego llegamos a la contradicción que no podemos tener ambas a la vez > en > >> > todo su esplendor. > >> > > >> > Y de ahí aparece traits como un elemento de composición que permite > >> > eliminar > >> > la herencia y reemplazarla por un concepto igualmente poderoso, más > >> > fácil de > >> > usar y que no se contradice con la encapsulación... > >> > > >> > Saludos! > >> > > >> >> > >> >> Saludos > >> >> GallegO > >> >> >> > >> > > >> > >> > > > > > > > > -- > > Saludos cordiales, > > > > Guillermo Schwarz > > Sun Certified Enterprise Architect > > > > > > > > > > > -- Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] http://www.clubSmalltalk.org -~----------~----~----~----~------~----~------~--~---
