Ehhh... no se a que te referis, pero hablo con conocimiento (parcial)
de causa porque trabaje ahi.
Andres.
2008/9/13 Guillermo Schwarz <[EMAIL PROTECTED]>:
> Pero es que antes hacìan casi todo en Smalltalk, cuando apareciò Java
> incluso aparecieron varios post de lo malo que habìa sido porque habìan
> tenido que migrar gran parte del còdigo a Java, pero al parecer no les
> funcionò...
>
> 2008/9/12 Andres Valloud <[EMAIL PROTECTED]>
>>
>> Guillermo,
>>
>> Con respecto a JP Morgan, no estan "volviendo" a Smalltalk porque
>> nunca se fueron.
>>
>> Andres.
>>
>>
>> 2008/9/12 Guillermo Schwarz <[EMAIL PROTECTED]>:
>> >
>> >
>> > 2008/9/12 Hernan Wilkinson [EMAIL PROTECTED]
>> >>>
>> >>>
>> >>
>> >> Sinceramente no entiendo lo que pones. Creo que estamos hablando de
>> >> cosas
>> >> distintas. Lo que yo quise poner es: un proxy (aProxy) instancia de la
>> >> clase
>> >> Proxy (por ejemplo) es un objeto. Por ser objeto y no clase ni nada
>> >> similar,
>> >> se encuentra en el "nivel" de los objetos.
>> >
>> >
>> > Mmmh, no.
>> >
>> > Un proxy es una clase. Cada vez que creas un proxy diferente es una
>> > clase
>> > diferente. Obviamente luego lo instancias para usarlo, pero como todas
>> > las
>> > clases.
>> >
>> >>
>> >> Un trait, por supuesto que es un objeto, pero se encuentra en un
>> >> "nivel"
>> >> distinto a los objetos "comúnes" o "concretos" (como el string "hola" o
>> >> el
>> >> número "1" o el aProxy).
>> >
>> >
>> > Si estudiaras Lisp te darías cuenta que no.
>> >
>> > Sólo en lenguajes como VB existen esas distinciones irrelevantes...
>> >
>> >>
>> >> En realidad se encuentra en un "meta-nivel" (un nivel que describe el
>> >> nivel de los objetos, por eso meta) y es por eso que nunca podrían ser
>> >> iguales.
>> >
>> >
>> > Mmmhh. EN el caso de las meta clases te lo compro. De hecho nunca puedes
>> > tener acceso a las metaclases a menos que uses reflection. Y aún así
>> > nunca
>> > he visto una aplicación útil. Ok, la he visto, pero era un caso muy
>> > puntual...
>> >
>> >>
>> >> Los traits son como clases, y de la misma manera que no puedo comparar
>> >> un
>> >> Proxy con una clase, no puedo comparar un Proxy con un trait. Esto es
>> >> lo que
>> >> quise decir.
>> >
>> >
>> > Pero si hacen lo mismo. Y ambos son clases. Sólo que uno es más ordenado
>> > y
>> > el otro es más desordenado...
>> >>>
>> >>>
>> >>>>
>> >>>> Por ejemplo, un proxy adolece del problema del "identidad" mientras
>> >>>> que
>> >>>> eso ni se puede pensar en un trait.
>> >>>
>> >>>
>> >>> Eso de la identidad, a mi parecer, es màs un detalle de implementaciòn
>> >>> que un feature que quiera que tenga el lenguaje. No necesito que cada
>> >>> objeto
>> >>> exista una sola vez en la memoria, ni me importa. Si el compilador o
>> >>> el
>> >>> runtime son capaces de ahorrar memoria, bien. Significa que estàn bien
>> >>> hechos, pero si complica el modelo de programaciòn es una basura y hay
>> >>> que
>> >>> botarlo.
>> >>
>> >> No es a lo que me refiero, intuyo que estás confundiendo identidad con
>> >> cantidad de objetos necesarios para representar el mismo ente.
>> >
>> >
>> > No. Hace unos 10 o 15 años atrás se volvieron todos locos con eso de la
>> > identidad y creo que fue una de las cosas que casi hicieron fracasar a
>> > la
>> > orientación a objetos. Es irrelevante para nosotros y sólo a un fanático
>> > de
>> > Lisp le podría interesar.
>> >
>> >>
>> >> Cuando hablo del problema de identidad me refiero a que una vez que el
>> >> proxy forwardea el mensaje al objeto proxeado, "self" pasa a estar
>> >> bindeado
>> >> con el objeto proxeado
>> >
>> >
>> > Que buen spanglish ;-) Si mi profesora de castellano me viera :))
>> >
>> >>
>> >> y si no hay manera que el proxy se entere que se envía un mensaje que
>> >> el
>> >> también tiene intención de "controlar".
>> >
>> >
>> > Granted. Ese es un problema, pero los "constructores de proxies" saben
>> > eso,
>> > o por lo menos eso espero. ¿Traits lo soluciona?
>> >
>> >>
>> >> Esto no sucede en lenguajes de prototipación con delegación como Self,
>> >> donde implementar un proxy o cualquier tipo de wrapper es trival.
>> >
>> >
>> > Qué interesante.
>> >
>> >>
>> >> A eso me refería y lo ponía como ejemplo de lo que aclaré en el párrafo
>> >> anterior.
>> >
>> >
>> > Bueno en ese caso supongo que bastaría con arreglar el compialdor de
>> > Smalltalk para que sea "proxy aware".
>> >>
>> >>
>> >>>
>> >>>
>> >>> Por ejemplo, en Smalltalk una vez (circa 1996) bajè una biblioteca
>> >>> para
>> >>> Smalltalk/V que se encargaba de guardar objetos como lo hace
>> >>> Hibernate, el
>> >>> asunto es que cuando volvìan del disco (o la BD) se preocupaba
>> >>> Smalltalk que
>> >>> no se crearan copias. Hasta ahì todo bien. El ùnico problema es que
>> >>> cuando
>> >>> programas en cualquier lenguaje, eso no pasa. Por ejemplo, usa Java
>> >>> para
>> >>> leer de una base de datos, y has scan de una tabla con JDBC, te
>> >>> quedaràs con
>> >>> 2 copias de los mismos objetos. Eso es lo natural. Eso de que el ORM
>> >>> se
>> >>> ponga a manejar los objetos en memoria y que cuando cambias uno se te
>> >>> cambien todos es contraproducente. He trabajado en proyectos asì y es
>> >>> un
>> >>> asco, al final nadie entiende nada, es parche sobre parche y el
>> >>> usuario lo
>> >>> ùnico que quiere es que boten el sistema a la basura.
>> >>
>> >> Bueno, no se que experiencia tuviste, pero yo tuvo experiencias
>> >> complemtamente contrarias y justamente algo que es fundamental de un
>> >> framework de mapping objeto relacional es asegurarse que EN LA MISMA
>> >> TRANSACCION, si una fila se lee dos veces, que la misma sea
>> >> representada en
>> >> un único objeto... veo que tenemos varias diferencias... que
>> >> interesante!
>> >> :-)
>> >
>> >
>> > Sí, y en HIbernate eso es como una patada en la wata. No entiendo porque
>> > copiaron a Smalltalk a la pata, bueno en realidad sí lo entiendo,
>> > Smalltalk
>> > es la implementación de referencia, aunque todos digan lo contrario y
>> > estén
>> > atrasados como 20 años ;-)
>> >
>> > El punto está en que se vuelve poco natural eso de que los objetos "se
>> > compacten" en memoria y no pueda naturalmente tener objetos repetidos.
>> >
>> > Caso en cuestión: No quiero que los objetos que estoy leyendo en mi tx
>> > sean
>> > leídos en tú tx. Eso es así en las bd relacionales, pero en Hibernate
>> > hacen
>> > todo lo posible porque los objetos no se repitan, como si el estado real
>> > fuera el estado en RAM, y el estado en al BD fuera sólo un respaldo,
>> > cuando
>> > es todo al revés.
>> >
>> > Lo que está en el BD es lo que manda porque las BD tiene 2 phase commit,
>> > etc., mientras que en RAM no hay transaccionabilidad, de modo que todo
>> > lo
>> > que hagas es una soberana cochinada poco confiable.
>> >
>> > Imagina que leo algo en ram y lo muestro en la pantalla, por ejemplo una
>> > lista de clientes, o de proveedores, y leugo presiono sobre un proveedor
>> > y
>> > le envío un back order, ¿no estoy usando los datos de la pantalla? ¿es
>> > decir
>> > los datos que están en ram? ¿Y que pasa si entre que miro la lista y
>> > presiono el back order pasan 5 días? (ok, estoy exagerando, pero todo
>> > peude
>> > haber cambiado mucho)
>> >
>> > Entonces me encuentro con objetos de ahora y objetos super viejos, todos
>> > mezclados en ram, y por alguna razón el orm asume que "esto es la
>> > verdad" y
>> > luego los usuarios se quejan que los datos en pantalla no se refrescan
>> > con
>> > lo que sus compañeros de trabajo están actualizando y los programadores
>> > se
>> > vuelven monos llamando "update" sobre cada objeto que aparece en la
>> > pantalla, y para colmo un sólo update se puede resolver con 12 mil SQL,
>> > porque los ORM son un chiste en este momento, claro y en Hibernate
>> > recomiendan hacer join, pero Oracle sólo resiste hasta 12 o 24 tablas al
>> > mismo tiempo en el mismo join... qué chanta...
>> >
>> > Y para que decir que se demora varios minutos...
>> >>>
>> >>>
>> >>> Me da risa porque esto pasò en JP Morgan usando Java y Hibernate, pero
>> >>> JP
>> >>> Morgan es conocida por usar Smalltalk.
>> >>
>> >> Y el problema es porque usaron Java... se deberían haber quedado con
>> >> Smalltalk! jaja.
>> >
>> >
>> > JA JA, tengo entendido que están volviendo a Smalltalk, por algo será,
>> > claro
>> > que en Chile con suerte entraron al mundo Java porque antes estaban con
>> > Fox
>> > 8-P (creo que eso es peor que COBOL).
>> >
>> >
>> > [...] At first I hoped that such a technically unsound project would
>> > collapse but I soon realized it was doomed to success. Almost anything
>> > in
>> > software can be implemented, sold, and even used given enough
>> > determination.
>> > There is nothing a mere scientist can say that will stand against the
>> > flood
>> > of a hundred million dollars. But there is one quality that cannot be
>> > purchased in this way---and that is reliability. The price of
>> > reliability is
>> > the pursuit of the utmost simplicity. It is a price which the very rich
>> > find
>> > most hard to pay.
>> >
>> > -- C.A.R. Hoare, "The Emperor's Old Clothes", Turing Award Lecture
>> > (1980)
>> >>
>> >>
>> >>>
>> >>>
>> >>>>
>> >>>> 3) Recalco lo que dice Gabriel, no hay que perder nunca la pata
>> >>>> conceptual. Conceptualmente trait es distinto de clase y de proxy,
>> >>>> representan cosas completamente distintas.
>> >>>
>> >>>
>> >>> Claro como digas. Y objeto tambièn es distinto. Pero una clase es un
>> >>> objeto y todo objeto pertenece a una clase.
>> >>
>> >> jaja, no, no es como digo yo. Perdona si soné agresivo o imperativo.
>> >> Por
>> >> eso aclaré en el mail que lo escribía rápido y esperaba que nadie se
>> >> molestara... indudablemente no alcanzo... este intercambio de opiniones
>> >> siempre terminar hiriendo suceptibilidades cuando se hace por mail...
>> >> si
>> >> fuera de manera personal no pasaría... en fin.
>> >
>> >
>> > No hay ofensa. No lo tomo a mal.
>> >>
>> >> Igual, no todo objeto pertenece a una clase. Me voy a poner en
>> >> quisquilloso como lo hago cuando enseñamos en la facu
>> >
>> >
>> > JA JA JA
>> >
>> > Eso lo llamo "cuando el cerebro empieza a funcionar" ;-)
>> >
>> >>
>> >> y espero que no te sigas molestando... si te molesto perdoname, no es
>> >> mi
>> >> intención... O sea, la relación "instancia de" no es una relación de
>> >> pertenencia....
>> >
>> >
>> > Qué interesante. O sea que una instancia de un problema no es un ejemplo
>> > de
>> > un problema.
>> >
>> > Claro, uno define los términos como quiere, pero si lso defines a tu
>> > arbitrio eso no cambia el fondo de la discusión.
>> >
>> > Por lo menos en mi "facu", un objeto sí era un elemento del conjunto
>> > representado por el tipo. Era así en todos los lenguajes. Y cuando
>> > llegamos
>> > a Smalltalk, vino un argentino o uruguayo (sin ánimo de ofender a nadie)
>> > y
>> > dijo que no, que los tipos y las clases eran cosas distintas e hizo sus
>> > malabares en clase, pero luego de pensarlo algunos meses esa idea no me
>> > condujo a nada. Desaofrtunadamente parece de escaso valor intelectual
>> > una
>> > idea que no produce resultados en la práctica, aunque debo reconocer que
>> > en
>> > su momento la explicación fue convincente.
>> >
>> > En el mundo de la OO hay tanto tipo que dice que sabe, que de repente te
>> > mandan por un derrotero que no es más que un callejón sin salida y de
>> > donde
>> > te toma años salir.
>> >
>> >>
>> >> pero igual, en todo caso, la relación instancia de solo existe en
>> >> ambientes de objetos con clasificación (aristotélicos) y no en aquellos
>> >> con
>> >> prototipos (contemporaneos) donde un objeto existe por si mismo si
>> >> necesidad
>> >> de una clase...
>> >
>> >
>> > ok, self es prototípico, y no hay instancias en él, aunque sí muchos
>> > objetos
>> > clonados y que luego evolucionaron porque a diferencia de Smalltalk, en
>> > Self
>> > son los objetos los que determinan su propio comportamiento, ya que no
>> > existe una clase que le diga a cada objeto de qué tipo es y por lo tanto
>> > cuál es su protocolo, entiendo, me parece un desorden descomunal, pero
>> > lo
>> > entiendo...
>> >
>> >
>> >>
>> >> un buen ejemplo de estos lenguajes es Self.
>> >
>> >
>> > ah, ok gracias por validarme ;-)
>> >>>
>> >>>
>> >>> Todo comportamiento està asociado a una clase y por lo tanto el
>> >>> comportamiento de 2 objetos de la misma clase es necesariamente el
>> >>> mismo. La
>> >>> herencia es especializaciòn de las clases y por lo tanto de su
>> >>> comportamiento. De modo que al usar traits estamos logrando que
>> >>> comportamientos que son comunes a clases que son de jerarquìas
>> >>> independientes, compartan el còdigo usando traits o proxies, porque
>> >>> conceptualmente ambos hacen lo mismo.
>> >>
>> >> Pero un proxy solo proxea UN OBJETO,
>> >
>> >
>> > Si lo pones en un factory y sólo instancias objetos a través de un
>> > factory,
>> > entonces todos tus objetos están proxiados. De hecho si mal no recuerdo
>> > hay
>> > una manera de hacer eso, creo que es en Smalltalk, definiendo un
>> > método...
>> > ya se me olvidó, pero en fin...
>> >
>> >>
>> >> por lo tanto solo puede modificar el comportamiento de UN OBJETO,
>> >> mientras
>> >> que un trait "complementa" el comportamiento defino en UNA CLASE que
>> >> hacer
>> >> que cambie el comportamiento de TODOS LOS OBJETOS instancias de ella...
>> >
>> >
>> > O sea le chanto el proxy en el factory, ¿algo más?
>> >
>> >>
>> >> para mi no tienen nada que ver conceptualmente.
>> >
>> >
>> > Hasta el momento sóplo estamos hablando de mecanismos, no de lo que
>> > hacen.
>> > Ambos agregan comportamiento a clases sin tocarlas, ese es el objetivo
>> > conceptual al fin y al cabo. Respecto del mecanismo me parece que es
>> > casi lo
>> > mismo, si el traits tiene ayuda del compiladorm, si escribo "trait X
>> > {...}"
>> > en vez de "class X {...}" me da lo mismo, por convención digo que todos
>> > los
>> > traits deben terminar en Trait y listo "class XTrait {...}"...
>> >
>> > No veo diferencia, aunque claro un programador puede demorarse meses en
>> > entender eso. Recuerdo un proyecto de 1.5 años en el que los
>> > programadores
>> > reclamaron durante todo el proyecto porque usábamos runable que en Java
>> > es
>> > un asco, mientras que en Smalltalk usas un bloque y listo. Ok, pero
>> > conceptualmente es "delayed execution", en Lisp se llama quote, y qué?
>> > Es lo
>> > mismo!!!
>> >>>
>> >>>
>> >>> En el mismo paper introductorio de traits que mandè antes dice que los
>> >>> traits son una manera de ordenar tanta creaciòn de proxies y crear
>> >>> proxies
>> >>> màs genèricos, y màs pequños por cierto, ya que los traits permiten
>> >>> componer
>> >>> los proxies (y nòtese que los proxies ya se podìan componer de antes
>> >>> de
>> >>> manera trivial).
>> >>
>> >> Estas seguro que estás hablando de proxies y no de mix-ins? El paper
>> >> "Traits: Composable Units of Behaviour" (que creo que es al que te
>> >> referís)
>> >> no habla de proxies para nada (por lo menos no lo encontre recien
>> >> haciendo
>> >> un search ni lo recuerdo de cuando lo leí hace rato ya...).
>> >
>> >
>> > Ah bueno es que es refácil impelemntar mixins con proxies. Pero el punto
>> > es
>> > para aquellos que no entienden traits. Lo chistoso es que no hay nada
>> > que
>> > entender. Si sabes proxies, ya sabes Traits. El código es irreconocible,
>> > estoy de acuerdo, pero al final es agregar conportamiento a una clase
>> > sin
>> > tocarla.
>> >
>> > ok, quizás te parece difícil la abstracción que estoy haciendo, porque
>> > de
>> > hecho la abstracción es lo único que se me hace fácil. Soy al revés de
>> > todo
>> > el resto de los mortales.
>> >>
>> >>
>> >>>
>> >>>
>> >>>>
>> >>>> 4) No es lo mismo el concepto de trait en Self que en Smalltalk, por
>> >>>> eso
>> >>>> quizá la confusión con proxy... es así?
>> >>>
>> >>> No lo sè. Quizàs podrìas iluminarnos al respecto.
>> >>
>> >> Bueno, no es mi intención iluminar a nadie... comenté sobre lo que
>> >> quise
>> >> poner más arriba.
>> >
>> >
>> > En realidad lo interesante son los disagreements, porque generalmente en
>> > esos disagreements es dónde se encuentra el conocimiento. Me gustó eso
>> > de
>> > Self que comentaste. Si tienen resuelto el problema del objeto que llama
>> > self, entonce tal vez podríamos hacer un backport a Smalltalk (estoy
>> > asumiendo que todos saben que Self es algo así como una versión
>> > posterior de
>> > Smalltalk).
>> >
>> >
>> > ¿Alguien tendrá un mapa de los lenguajes de objetos así como se usaban
>> > hace
>> > 20 años para tener una visión general de todos los inventos que se han
>> > hecho
>> > sobre Smalltalk?
>> >>>
>> >>>
>> >>>>
>> >>>> 5) El encapsulamiento no solo se rompe en la subclasificación por
>> >>>> acceder a las variables de instancias sino por el hecho de poder
>> >>>> redefinir
>> >>>> comportamiento o utilizar super, etc.
>> >>>
>> >>>
>> >>> Pero si redefines comportamiento ¿lo haces en la clase base o en la
>> >>> derivada?
>> >>>
>> >>>>
>> >>>> Hacer estas cosas implica saber como está implementada la superclase
>> >>>
>> >>>
>> >>> Si fuera asì, bastarìa con hacer que las variables de instancia no
>> >>> fueran
>> >>> visibles en las subclases. Crear acccessor como propuso alguien antes.
>> >>>
>> >>>>
>> >>>> y por lo tanto hace que las clases sean "cajas blancas" y no "cajas
>> >>>> negras", por eso se dice que rompe el encapsulamiento....
>> >>>
>> >>>
>> >>> Mmhh, no es lo que leì. Si nada se rompe, ¿cuàl es el problema?
>> >>>
>> >>> Y si algo se rompe ¿què es? ¿la clase base o la derivada?
>> >>
>> >> No se rompe nada, es una analogía. Lo que sucede es que es posible que
>> >> deje de funcionar algo que antes funcionaba.
>> >
>> >
>> > Ok, a eso se le llama en inglés "break". Y significa que algo dejó de
>> > funcionar.
>> >
>> > Es frustrante para un desarrollador de la clase X que deje de funcionar
>> > su
>> > clase porque la clase P fue actualizada y ahora ya no funcona.
>> >
>> > En el mundo de la ingeniería de software encontraron que lo mejor es
>> > correr
>> > pruebas de compatibilidad y mantener la compatibilidad hacia atrás
>> > aunque
>> > el código sea inutilizable y en el mundo Java "deprecan" la clases.
>> >
>> > En el mundo Smalltalk crearon SUnit y diría que siguen el mismo patrón
>> > de
>> > comportamiento, mantienen lo mal para que todo siga fucionando, pero
>> > supongo
>> > que todos sabemos que Smalltalk no satisface LSP (Liskov Substitution
>> > Principle).
>> >>>
>> >>>
>> >>>
>> >>> Claramente la que se rompe es la clase derivada. Si la jerarquìa es
>> >>> muy
>> >>> profunda, se transforma en DLL hell, pero en este caso inheritance
>> >>> hell. Las
>> >>> clases base se vuelven intocables, sino trata de modoficar Object, por
>> >>> ejemplo agrègale una nueva variable de instancia y luego remueve otra,
>> >>> pero
>> >>> reemplaza los mètodos para que usen la nueva variable y que todo siga
>> >>> compilando. Apuesto a que se te congela la imagen, o al menos, te
>> >>> queda en
>> >>> un estado inconsistente.
>> >>
>> >> Bueno, en realidad no se puede agregar una variable de instancia a
>> >> Object
>> >> por motivos que no viene al caso comentar (y espero que no te lo
>> >> moleste si
>> >> no lo hago...)
>> >
>> >
>> > Claro, que el runtime no lo aguanta.
>> >
>> > No hay problema, gracias por la conversación interesante.
>> >
>> > ¿Dónde te mando la factura? ;-)
>> >
>> > --
>> > 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
-~----------~----~----~----~------~----~------~--~---
