En Nueva York.
2008/9/18 Guillermo Schwarz <[EMAIL PROTECTED]>:
> 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
>> >
>> > >
>> >
>> >>
>
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
http://www.clubSmalltalk.org
-~----------~----~----~----~------~----~------~--~---
