Bueno, si no entienden dejèmoslo hasta ahí. No se le pueden pedir peras al olmo y en realidad el concepto es demasiado bàsico como para seguir dàndole màs vueltas.
Cambiando de tema a uno màs pràctico, lo que al parecer està màs en sintonìa con la gente que participa en este foro: Hay un proyecto interesante en Squeak que se llama Croquet y que consiste en un mundo virtual en 3D. Eliot Miranda está creando Quawk: http://www.mirandabanda.org/cogblog/2008/06/06/cog/ En tèrminos de Eliot Miranda: "I'm delighted to say that Qwaq<http://www.qwaq.com/>has taken me on to write a fast Croquet VM and that the VM is to be released under the Qwaq open source licence (an MIT license<http://www.opensource.org/licenses/mit-license.php>). I'm going to blog about the VM here as I implement it. The blog is a chance for me to record design decisions as I go along, receive better ideas from you, dear reader, and to hand out the whitewash<http://www.pbs.org/marktwain/learnmore/writings_tom.html> ." Por el momento, hasta dònde he podido ver, aùn no es un producto maduro, pero tiene un potencial enorme. Saludos, Guillermo. 2008/9/24 Emilio Oca <[EMAIL PROTECTED]> > > Aporte? Seria reiterar lo que otros han dicho. Para alguien que se ve > necesitado de repetir todo aquello que leyo sin entender, incapaz de > sostener un hilo de discucion. > > Emilio > > > El 24/09/08, Guillermo Schwarz <[EMAIL PROTECTED]> escribió: > > Ah, qué profundo y bien argumentado el aporte. > > > > ¿Algún ejemplo que justifique tu postura? > > La argumentación puede venir de conclusiones basadas en axiomas y > teoremas > > demostrados a partir de esos axiomas mediante reglas lógicas, o bien > pueden > > ser simplemente ejemplos que muestran que algo es verdad y que no son > > demostrables, como la fuerza de gravedad. > > > > Otra cosa es simplemente abrir la boca por abrirla... > > 2008/9/24 Emilio Oca <[EMAIL PROTECTED]> > > > >> > >> No, Guillermo, simplemente estas equivocado, en general. > >> > >> Emilio > >> > >> > >> On 9/24/08, Guillermo Schwarz <[EMAIL PROTECTED]> wrote: > >> > > >> > Estimado Gabriel, > >> > > >> > Muchas gracias por tomarte el tiempo en contestar mi publiucación. > >> > > >> > Sí, si me suena el señoir Ingals, gracias. Aunque creo que el señor > >> > Meyer > >> > pesa más en la comunidad principalmente porque el mensaje es más > >> reducido, a > >> > mi entender porque el señor Meyer se concentra en lo importante, > >> > mientras > >> > que el señor Ingals se concentra en los detalles. Ambos tipos de > >> > personalidades son importantes, pero si quieres aprender deberías > >> > concentrarte primero en lo importante, ya que los detalles los > >> > aprenderás > >> de > >> > todas formas. Si por el contrario te concentras en los detalles, puede > >> que > >> > descubras lo importante como puede que no. > >> > > >> > Respecto de lo que escribió el señor Ingals concuerdo en un 100% y me > >> parece > >> > interesante el punto de vista, pero ¿no serán demasiados puntos a > tener > >> en > >> > cuenta? > >> > > >> > Lo sigo porque en vez de basarse en pocas ideas, presenta una serie de > >> ideas > >> > que no son fáciles de entender por sí solas, por ejemplo: > >> > > >> > Leverage: When a system is well factored, great leverage is > available > >> to > >> > users and implementers alike. > >> > Take the case of sorting an ordered collection of objects. In > >> Smalltalk, > >> > the user would define a message called sort in the class > >> OrderedCollection. > >> > When this has been done, all forms of ordered collections in the > system > >> will > >> > instantly acquire this new capability through inheritance. As an > aside, > >> it > >> > is worth noting that the same method can alphabetize text as well as > >> > sort > >> > numbers, since comparison protocol is recognized by the classes which > >> > support both text and numbers. > >> > The benefits of structure for implementers are obvious. To begin > >> with, > >> > there will be fewer primitives to implement. For instance, all > graphics > >> in > >> > Smalltalk are performed with a single primitive operation. With only > one > >> > task to do, an implementer can bestow loving attention on every > >> instruction, > >> > knowing that each small improvement in efficiency will be amplified > >> > throughout the system. It is natural to ask what set of primitive > >> operations > >> > would be sufficient to support an entire computing system. The answer > to > >> > this question is called a virtual machine specification: > >> > > >> > Ocurre que los sistemas "well factored" no pueden tener código > repetido. > >> O > >> > por lo menos se esperaría que tuvieran poco código repetido, sino no > se > >> > entiende eso de "well factored". Simpáticamente ese es uno de los > temas > >> que > >> > más contrariedad provoca en este grupo, porque al parecer sólo > entienden > >> de > >> > este paper lo que les conviene o lo que no contradice sus creencias > >> > irracionales. Está ampliamente documentado que todas las personas > >> funcionan > >> > así, en el fondo buscan corroborar sus creencias irracionales y con > eso > >> > sicólogicamente les basta, desafortunadamente no es así como avanza la > >> > ciencia. > >> > > >> > El punto que estábamos dicutiendo es si corresponde crear un sistema > >> > partiendo como principio unificador del proyecto "modelar el mundo > >> > real". > >> A > >> > este respecto el señor Ingals menciona: > >> > > >> > > >> > Polymorphism: A program should specify only the behavior of objects, > >> > not > >> > their representation. A conventional statement of this principle > is > >> that > >> > a program should never declare that a given object is a SmallInteger > or > >> > a > >> > LargeInteger, but only that it responds to integer protocol. Such > >> > generic > >> > description is crucial to models of the real world. > >> > Consider an automobile traffic simulation. Many procedures in such > a > >> > system will refer to the various vehicles involved. Suppose one wished > >> > to > >> > add, say, a street sweeper. Substantial amounts of computation (in the > >> form > >> > of recompiling) and possible errors would be involved in making this > >> simple > >> > extension if the code depended on the objects it manipulates. The > >> > message > >> > interface establishes an ideal framework for such an extension. > Provided > >> > that street sweepers support the same protocol as all other vehicles, > no > >> > changes are needed to include them in the simulation: > >> > Desafortunadamente cuando arriba dice "real world" se refiere a crear > >> > simulaciones del mundo real, es decir, si vas a construir una > >> > simulación, > >> > entonces el polimorfismo es útil. Como ustedes sabrán Smalltalk deriva > >> > en > >> > parte del lenguaje Simula y por ende había una espectativa de que este > >> > lenguaje también fuera usado para hacer simulaciones, por eso habla de > >> mundo > >> > real. El señor Ingals no está diciendo que los sistemas de información > >> deban > >> > construirse penando en modelar el mundo real, como al parecer alguien > >> > acá > >> > quiere hacernos creer. > >> > > >> > Saludos cordiales, > >> > Guillermo. > >> > > >> > > >> > > >> > 2008/9/23 Gabriel <[EMAIL PROTECTED]> > >> > > >> > > > >> > > Mirá, no se trata de quien tiene experiencia y quien no. Cuando se > >> > discute se lo hace con argumentos, porque si no gana siempre el que > >> laburo > >> > mas años (por mas que durante esos años se haya trabajado de muy mala > >> > manera). > >> > > En cuanto al paper ese que me pasaste, interesante, lo voy a leer, > >> quiza > >> > ahi existan argumentos que sostengan lo que decis, en principio no > >> conozco > >> > ninguno. > >> > > Por otro lado, con respecto a experiencias que contradigan lo que > >> > > decis > >> te > >> > doy un ejemplo: Smalltalk. > >> > > Si te cabe duda leete este paper que es bastante viejito: > >> > > > >> > > >> > http://users.ipa.net/~dwighth/smalltalk/byte_aug81/design_principles_behind_smalltalk.html > >> > > Lo escribió un tal Daniel H. H. Ingalls, no se si te suena. > >> > > Saludos. > >> > > > >> > > > >> > > > >> > > El 23 de septiembre de 2008 15:07, Guillermo Schwarz > >> > <[EMAIL PROTECTED]> escribió: > >> > > > >> > > > >> > > > >> > > > >> > > > > >> > > > > >> > > > En mi pobre experiencia (comparada por supuesto con tu vasta > >> experiencia > >> > en el tema ;-), la recomendaciòn de "modelar la realidad" rara vez > >> funciona, > >> > y cuando funciona, lo hace por un periodo tan breve y en forma tan > >> corrupta, > >> > que es mejor no seguir esa recomendaciòn. > >> > > > > >> > > > Hay otros que tienen la misma visiòn: > >> > > > > >> > > > > >> > > >> > http://www.developertutorials.com/tutorials/php/what-is-object-oriented-programming-070130/page2.html > >> > > > > >> > > > "Reasoning too much in terms of the real world can actually be > >> > detrimental to software quality" > >> > > > > >> > > > > >> > > >> > http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel1/2/11070/00511974.pdf?arnumber=511974 > >> > > > > >> > > > Y lo dice un señor llamado Bertrand Meyer... no sé si les suena... > >> > > > > >> > > > Si tienen experiencias que contradigan lo que digo o al señor > Meyer > >> > serìa bueno que las compartieran para que todos aprendamos de su > infita > >> > sabidurìa... > >> > > > > >> > > > Saludos cordiales, > >> > > > Guillermo. > >> > > > > >> > > > > >> > > > 2008/9/22 Gabriel <[EMAIL PROTECTED]> > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > > >> > > > > Es increible que no puedas entender que modelar la realidad no > >> > significa modelarla entera. Obviamente que siempre es un modelo > >> > simplificado, la realidad es infinita, ni siquiera creo que exista la > >> > posibilidad de hacer un modelo completo de toda la realidad. > >> > > > > Pero a ver si entendes, podes modelar algo y tratar de no perder > >> > > > > de > >> > vista el gap semantico y no por eso eso que modelaste modele la > realidad > >> > entera! lo importante es que siempre que sea posible te acerques lo > mas > >> que > >> > puedas. > >> > > > > Si queres no repetir codigo podes hacerlo con programación > >> procedural > >> > y no se para que complicas todo con objetos y mensajes, en el lugar > que > >> va > >> > el mismo codigo llama a la misma funcion y listo. > >> > > > > > >> > > > > > >> > > > > El 22 de septiembre de 2008 1:47, Guillermo Schwarz > >> > <[EMAIL PROTECTED]> escribió: > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > 2008/9/18 Abel Armoa <[EMAIL PROTECTED]> > >> > > > > > > >> > > > > > > > >> > > > > > > Guillermo, hay algo que no entiendo cuando decís: > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > Proxy: Clase que permite agregar comportamiento a otras > >> clases > >> > sin usar herencia, sino usando composiciòn, de modo que la clase X > >> > preexistente adquiere el comportamiento del Proxy P cuando esta clase > se > >> > encuentra envuelta en el proxy P. > >> > > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > ¿Cómo puede ser que una clase preexistente adquiera nuevo > >> > comportamiento mediante el Proxy? > >> > > > > > > >> > > > > > > >> > > > > > a := Object new. > >> > > > > > a := PersistentProxy for: a. > >> > > > > > > >> > > > > > la idea es que PersistentProxy es una clase que al mandarle el > >> > mensaje for: crea una nueva instancia de sì misma que intercepta todos > >> los > >> > mensajes. > >> > > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > La únca forma que se me ocurre que pueda pasar esto es que > un > >> > proxy se maneje a nivel meta y redefina o agregue comportamiento a la > >> clase. > >> > Pero sé que los Proxy no hacen esto (o por lo menos no es su objetivo > >> > inicial). > >> > > > > > > >> > > > > > > >> > > > > > Si. > >> > > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > Otra duda que me surge es cómo hacés para envolver una clase > >> con > >> > un Proxy. Porque la implementación de Proxy que yo conozco es la de un > >> > objeto que tiene como colaborador interno a otro objeto. El proxy > recibe > >> los > >> > mensajes de otros objetos y decide en cada caso si delega algo en su > >> > colaborador o no, si hace algo antes de delegar o después, etc. > >> > > > > > > >> > > > > > > >> > > > > > Sí. en Smalltalk si recuerdo bien, se redefine el mètodo > >> > doesNotUnderstand. En Java se utliza un mecanismo llamado Dynamic > Proxy > >> que > >> > involucra al compilador. Me da la impresiòn que es màs sofisticado el > >> > mecanismo en Smalltalk porque permite redefinir mètodos, mientras que > en > >> > Smalltalk sòlo funciona si llegas al mètodo "doesNotUnderstand". > >> > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > ¿A qué te referís cuando decís que le agregás comportamiento > a > >> la > >> > clase? > >> > > > > > > >> > > > > > > >> > > > > > desde el punto de vista del usuario del objeto, el objeto ha > >> > adquirido comportamiento que antes no tenìa. > >> > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > Y después cuando decís: > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > Trait: Clase que permite agregar comportamiento a otras > >> clases > >> > sin usar herencia, sino usando composiciòn, de modo que las clase X es > >> > creada como un trait T del cual se extiende y se redefninen algunos de > >> sus > >> > mètodos. > >> > > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > No entiendo a qué te referís con composición de clases. > >> ¿Podrías > >> > explicar un poco esto? > >> > > > > > > >> > > > > > > >> > > > > > La idea es que las cuando estàs creando tus clases, puedes > usar > >> "is > >> > a" o "has a", por ejemplo, un una manzana "is a" fruta, un auto "has > a" > >> > motor, etc. > >> > > > > > > >> > > > > > Cuando utilizas "has a" estàs pensando en composiciòn mientras > >> que > >> > cuando estàs usando "is a" estàs usando herencia. > >> > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > Menos còdigo => menos costo > >> > > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > Para mi en realidad la cantidad de código no es importante, > >> sino > >> > cuán bien modelado está el problema a tratar. Qué tanto se acerca mi > >> modelo > >> > a la realidad. Y ahí sí, cuanto más se acerca => menos costo (pero no > >> creo > >> > que influya directamente en el costo, sino porque el modelo va a ser > más > >> > fácil de entender, mantener, reutilizar, extender, etc.) > >> > > > > > > >> > > > > > > >> > > > > > Desafortunadamente la orientaciòn a objetos no tiene nada que > >> > > > > > ver > >> > con la realidad, para eso estàn los casos de uso, es decir, el > >> modelamiento > >> > de las funcionalidades basadas en los "casos" en que el sistema serà > >> usado. > >> > Una vez que eso està modelado, los objetos son simplemente mecanismos > de > >> > implementaciòn. > >> > > > > > > >> > > > > > Los objetos del dominio (del problema) no deben ser màs del > 10% > >> de > >> > los objetos del sistema y hasta donde he podido ver nunca estàn > listos, > >> > nunca representan adecuadamente la "realidad", sino màs bien > satisfacen > >> los > >> > requerimientos en el mejor de los casos y punto. > >> > > > > > > >> > > > > > Un tìpico ejemplo son las direcciones. Por ejemplo los > clientes > >> > tienen direcciòn. La direcciòn tiene calle, nùmero, telèfono, comuna, > >> ciudad > >> > y paìs. El cliente puede tener ademàs un telèfono celular. El telèfono > >> > normal puede tener ademàs una direcciòn y un contacto, donde el > cantacto > >> es > >> > una persona que trabaja en esa direcciòn y que tìpicamente tiene un > >> cargo. Y > >> > todo eso sòlo para representar la direcciòn de un cliente. > >> > > > > > > >> > > > > > Luego un cliente sale con el pastelito de que tiene màs de una > >> > direcciòn, una direcciòn con màs de un telèfono, un telèfono con màs > de > >> un > >> > contacto, un contacto con màs de un cargo. > >> > > > > > > >> > > > > > Es muy difìcil de implementar para ser un problema tan simple, > >> pero > >> > principalmente porque "modelar la realidad" no deberìa ser el > objetivo. > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > Saludos, > >> > > > > > > Abel Armoa > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > -- > >> > > > > > > Saludos cordiales, > >> > > > > > > > >> > > > > > > Guillermo Schwarz > >> > > > > > > Sun Certified Enterprise Architect > >> > > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > -- > >> > > > Saludos cordiales, > >> > > > > >> > > > Guillermo Schwarz > >> > > > Sun Certified Enterprise Architect > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > >> > > >> > > >> > -- > >> > Saludos cordiales, > >> > > >> > Guillermo Schwarz > >> > Sun Certified Enterprise Architect > >> > > >> > > > >> > > >> > > >> > > >> > >> > > >> > > > > > > -- > > 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 -~----------~----~----~----~------~----~------~--~---
