Guillermo, No entiendo que tiene que ver esto que escribiste con lo que escribi anteriormente (y con lo que supuestamente estabas de acuerdo). Soy yo, o no me contestaste a mi? O sea, lo que veo es que se paso de "estoy de acuerdo" a una especie de exposicion donde se dicen cosas como
"En traits no trabajas usando herencia, sino usando composiciòn" Yo por lo menos no pregunte nada, y mucho menos eso... y si estabamos de acuerdo, porque hay que escribir todo este choclo de mensaje? No entiendo un pomo. > 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. /me is tempted to hold up a mirror again... Andres. 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 >> >> >> > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] http://www.clubSmalltalk.org -~----------~----~----~----~------~----~------~--~---
