En Chile o en Argentina?
2008/9/13 Andres Valloud <[EMAIL PROTECTED]>
>
> 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
> >
> > >
> >
>
> >
>
--
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
-~----------~----~----~----~------~----~------~--~---
