Si, tal cual Nacho, justamente una de las ventajas de la implementación de traits en Smalltalk es que la resolución de conflictos es explícita, te permite "sacar" métodos o utilizar "alias". Incisto, para mi Guillermo está hablando de algo distinto a lo que nosotros entendemos por trait... (o existe un gran confusión...)
2008/9/18 Ignacio Vivona <[EMAIL PROTECTED]> > >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. > Los traits no tienen la resolucion de conflictos explicita? asi tambien > como renombramiento de los metodos? > > > 2008/9/18 Guillermo Schwarz <[EMAIL PROTECTED]> > > 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 >>> > >>> > > >>> > >>> >>> >>> Guillermo Schwarz >>> Sun Certified Enterprise Architect >>> >>> >>> > > > -- > Bye, I love you! > Kisses everywhere & enjoy. > > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] http://www.clubSmalltalk.org -~----------~----~----~----~------~----~------~--~---
