En el evento de Sun JVM Summit que se celebró esta semana en Estados Unidos, los ingenieros de Google aprovecharon para anunciar a Noop un lenguaje para JVM con una sintaxis similar a Java pero enfocado en dos conceptos básicos que Java no tiene: Inyección de dependencias soportado en el core del lenguaje sin necesidad de recurrir a frameworks y Testability.
Su enfoque a la inyección de dependencias se basa en que una clase se puede crear de dos formas: a partir de objetos que el inyector puede proveer o a partir de a creación de dichos objetos en tiempo de ejecución ( usando new ), pero nunca a partir de una mezcla de ambos. Puedes leer los detalles de como piensan implementar esta funcionalidad en el wiki del proyecto.
Además del tema de Testability y la DI, Noop busca simplificar la programación para la JVM atacando casos comunes desde el core como la gestión de Nulls e impulsando las buenas prácticas de programación como favorecer la composición sobre la herencia. Características que a mi parecer lo hacen una opción interesante para mejorar la calidad de los desarrollos.
El proyecto esa en su fase inicial, pero ya puedes descargar la versión 0.1 para empezar a probarla. Algo interesante del lenguaje, es que además de proporcionar un intérprete para ejecución del lenguaje y un compilador a Byte Code (como lo hacen otros lenguajes de la JVM), también incluyen un "Traductor" cuyo propósito es generar código java a partir de Noop para permitir codificar en este lenguaje aunque tus proyectos sean 100% Java.
En un mundo cada vez más políglota, la JVM se ha visto fortalecida con esfuerzos como los de JRuby, Groovy, Scala y ahora Google entra al juego también con Noop.
Ya conocia este lenguaje, despues de la discusión sobre herencia-composición un compañero me mando un enlace y le estube echando un ojo.
De momento esta todavía verde, hay todavía cuestiones a resolver pero en las ideas fundamentales estoy totalmente de acuerdo con el enfoque de este lenguaje, de echo yo en mis desarrollos sigo, o intento, seguir la gran mayoría de las buenas practicas que este lenguaje promueve:
- Inyección de dependencias como parte del lenguaje
- testing como parte del lenguaje
- Composición como mecanismo de reutilización de primera clase
- Inmutabilidad
A mi me encata :P
Como ya he dicho en varias ocasiones, creo que al lenguaje Java habría que dejarlo en paz: cambiarlo lo mínimo, y todas esas otras cosas que queremos tener (todos los esfuerzos encaminados a conseguir mejores prácticas de programación tendrán siempre mi apoyo), las podemos introducir en nuevos lengaujes: Grroby es un "juguete" precioso y muy divertido.
Puesto que los lenguajes sobre la JVM pueden acceder a Java y sus APIs, no perdemos nada por el camino, y ganamos en claridad y simplicidad del lenguaje base: Java (estoy hasta los mismísimos bucles de tanta Annotation).
Bienvenido al infierno Java:
jeje
Yo por mi lado no pienso que las anotaciones sean un infierno y esto depende de la costumbre del programador esto se puede ver lado de .Net ya que las anotaciones denominadas atributos en esta plataforma han existido desde un principio y los programadores no se quejan tanto por el uso de las mismas.
En fin las anotaciones lo único que proveen son metadata para los tipos de Java y como bien dicen tanto el CLR y la Plataforma Java son plataformas basados en metadatos como los podemos ver en los assemblies de .Net o en los .class de java ya que estos son archivos de información o metadata que son consumidos por las Maquinas Virtuales (CLR, HotSpot), los JITs, las APIs como Reflection y todo esto con un fin producir una plataforma rica y manejada con la suficiente información para programar de una manera mas fácil. Entonces por que quejarnos de las anotaciones que nos ayuda a dar mas metadata a la plataforma Java sin tener que cambiar tanto el compilador.
Si usas muchas anotaciones en una misma clase como dicen los de Annotation Hell uno puede pensar que el diseño de esas clases no es el adecuado ya que se están mezclando diferentes comportamientos en un mismo objeto lo cual es un anti-patrón de diseño, entonces esto nos indica que debemos pensar un poco mas en el diseño de esas clases para no saturarlas de tanta anotación.
Preguntas:
¿Qué es más fácil programar un WebService con un montón de XML, o programar un WebService con anotaciones?
¿Qué es más fácil ahora J2EE o JEE 5.0 ó 6.0?
@Leonardoavs: "¿Qué es más fácil programar un WebService con un montón de XML, o programar un WebService con anotaciones?"
Prefiero el XML, por lo menos está todo centralizado y además no hay que tocar código si quieres cambiar ciertas cosas. Aunque el XML se puede considera como "codigo" (salvando las distancias)
logongas, recuerda que las anotaciones pueden ser sobre-escritas por ficheros xml, sin necesidad de tocar codigo
Rafa
@Logongas: Prefiero el XML, por lo menos está todo centralizado y además no hay que tocar código si quieres cambiar ciertas cosas. Aunque el XML se puede considera como "código" (salvando las distancias).
Bueno lo primero si tienes todo así de centralizado vas a tener un XML tan grande que los parseadores de los IDE se volverán lentos tratando de parsear los inmensos XMLs centralizados. Esto ya me paso con JDeveloper.
Segundo las anotaciones están en un solo lugar y este es en los class de los objetos.
Tercero no tengo que crear ningún parser para leer las anotaciones y si para leer los archivos XML ya que tengo toda la infraestructura para leer anotaciones en el API reflection de Java.
En cuanto a los Bean para saber el comportamiento que tienen hay que fijarse en ambos lugares en la clase del Bean y en el XML cosa que no es muy difícil pero si tediosa y rápido llena el IDE de gran cantidad de pestañas de XML y archivos .java, entonces con que necesidad se hace esto si se tienen anotaciones que están en el mismo archivo y me dicen exactamente lo que quiero.
Además para tener autocompletado en un IDE se necesita mínimo del XSD o si el XML es propietario hay que desarrollarlo y construir los parseadores necesarios y si vez bien a las anotaciones que son parte de Java ya los IDE vienen preparados con autocompletado para el lenguaje y algo muy con documentación.
Por ultimo se las ventajas del XML pero también pienso que el usar anotaciones no es tan malo. Para muestra un botón el nombre que utilizaste para referirte a mí usuario es una anotación Jajajaja no lo tome a mal es broma.
Como dicen por ahí el XML me permite diferentes configuraciones de un Bean para diferentes propósitos mientras que con las anotaciones solo se le puede dar un estado al objeto pero si este es el estado que requiere el objeto yo no veo que este mal.
Yo, como en casi todo, abogo por el equilibrio, pero puestos a argumentar:
Bueno lo primero si tienes todo así de centralizado vas a tener un XML tan grande que los parseadores de los IDE se volverán lentos tratando de parsear los inmensos XMLs centralizados. Esto ya me paso con JDeveloper.
¿Y el problema es de XML o de que tú lo usas mal? Por que si centralizas todas tus anotaciones en una clase tambien tendrás unos buenos problemillas.
Segundo las anotaciones están en un solo lugar y este es en los class de los objetos.
Ya por definición eso es más de un sitio, aparte de que al estar en los .class ... no los puedes leer sin "abrir" el .class. El XML es mucho más accesible en una aplicación de la que no tienes en ese momento el código fuente. Y no hablemos de modificaciones por que para eso hace falta el fuente y recompilar.
Tercero no tengo que crear ningún parser para leer las anotaciones y si para leer los archivos XML ya que tengo toda la infraestructura para leer anotaciones en el API reflection de Java.
El API para leer las anotaciones, y hasta un parser, vienen incluidos en el JRE, y para leer las anotaciones que no son del tipo retention-policy = runtime, vas a tener más que serios problemas para leerlas. No se si lo has probado, pero yo sí y hacen falta librerías externas o jugar con URLs, classloaders etc. para que no sea totalmente ineficiente.
Y con eso no quiero decir que usar XML sea estupendo y usar anotaciones lo peor, pero los argumentos a favor de las anotaciones y en contra del XML a mí no se me parecen a esos.
Yo anotaciones para cuatro cosas como si fueran código, no configuración, para todo lo demás, Master... digo XML, propiedades, ResourceBundles... :)
Hola Rafa,
no sabía que las anotaciones pudieran ser sobreescritas en XML.
Pero me surge una duda, ¿con esas anotaciones que generan código en las propias clases tambien funcionarian? Me refiero a la noticia de principio de mes Project Lombok, eliminando código "boilerplate" en Java
Pq una ventaja del XML ( o similares) es poder cambiar cosas en tiempo de ejecución.
En la discusión, nada más se ha hablado del nuevo lenguaje, pero la verdadera discusión consistiria en plantearse por qué Google ha tomado la decision de sacar un nuevo lenguaje.
Recordemos lo siguiente :
AppEngine -> Cloud computing
Android (SO para moviles) -> Movilidad
Chrome OS -> (SO para X86 y ARM) -> Escritorio
Noop ->?????
Desde mi perspectiva, considero que ésta es la pieza que une los 3 tres proyectos anteriores.
@greeneyed
¿Y el problema es de XML o de que tú lo usas mal? Por que si centralizas todas tus anotaciones en una clase tambien tendrás unos buenos problemillas.
Ok greeneyed estoy deacuerdo y si lees bien las entradas anteriores a este post notaras una que es mía y dice exactamente lo mismo que tu dices, lo de un xml centralizado lo dice @logongas en lo cual no estoy deacuerdo. Ahora con la parte de centralizar las anotaciones no hablo de poner todas las anotaciones en una sola clase hablo de que si le pongo las anotaciones que una clase necesite ellas van a estar centralizadas en esa clase y por lo tanto no va a ver perdida, si lees mejor notaras de lo que hablo.
Ya por definición eso es más de un sitio, aparte de que al estar en los .class ... no los puedes leer sin "abrir" el .class. El XML es mucho más accesible en una aplicación de la que no tienes en ese momento el código fuente. Y no hablemos de modificaciones por que para eso hace falta el fuente y recompilar.
Que es abrir el class para ti por que para mi es Persona.class o new Object().getClass() eso no tiene nada de difícil mi tampoco me voy a complicar abriendo archivos .class no necesito el código fuente ni nada por el estilo para las que son Runtime es cierto hay otras que pueden servir para documentación y que su información se guarde en los .class pero esas fueron diseñadas con ese propósito no con el propósito de ser consumidas por una aplicación abiertamente.
En cuanto a modificaciones estas perdido si me contestas para cualquier servidor, jvm la incógnita de que no hay que reiniciar una aplicación cuando se modifica un xml de hibernate o de spring me quito el sombrero casi siempre hay que hacerlo osea no podemos decir que el xml soluciona ese problema.
El API para leer las anotaciones, y hasta un parser, vienen incluidos en el JRE, y para leer las anotaciones que no son del tipo retention-policy = runtime, vas a tener más que serios problemas para leerlas. No se si lo has probado, pero yo sí y hacen falta librerías externas o jugar con URLs, classloaders etc. para que no sea totalmente ineficiente.
Yo siempre he pensado que si el arquitecto o la persona que diseño el API no hizo una anotación del tipo runtime fue por algo no solo por magia se debió de pensar que no se necesitaría o que habría un caso que no se debe de permitir, el RetentionPolicy marca los tipos de anotación y si es del class file o de fuente y tu quieres saber lo que dicen esas anotaciones es un problema diferente.
Estoy de acuerdo el xml es para configuraciones y para trasferencias de datos.
Es cierto me desvie del tema y hable de anotaciones cuando el hilo era de noop. Disculpas por los inconvnientes.
Que es abrir el class para ti por que para mi es Persona.class o new Object().getClass() eso no tiene nada de difícil mi tampoco me voy a complicar abriendo archivos .class no necesito el código fuente ni nada por el estilo para las que son Runtime es cierto hay otras que pueden servir para documentación y que su información se guarde en los .class pero esas fueron diseñadas con ese propósito no con el propósito de ser consumidas por una aplicación abiertamente.
Con "abrir" el .class quiero decir editarlo. Si quieres saber cómo se mapea una clase de la que no tienes el código fuente, si esta en XML haces un "more" del fichero XML y lo sabes en un instante. Si sólo tienes el .class no es tan sencillo. A eso me refiero. Y si crees que eso no es un problema es que no te ha tocado pegarte con código ajeno lo suficiente ;).
En cuanto a modificaciones estas perdido si me contestas para cualquier servidor, jvm la incógnita de que no hay que reiniciar una aplicación cuando se modifica un xml de hibernate o de spring me quito el sombrero casi siempre hay que hacerlo osea no podemos decir que el xml soluciona ese problema.
No digo que no se pueda hacer, pero modificar una clase no es tan sencillo como editar un fichero de texto. Necesitas compilar la clase y eso puede significar descargarte librerías, montarte el proyecto etc. etc. No estamos hablando de que el mismo que hace la aplicación lo modifique, que en ese caso ya lo tiene todo montado.
Si uno tiene la suerte de "consumir" únicamente su propio código y está al cargo de todo, no hay muchas diferencias. Pero hay todo un mundo ahí fuera donde las cosas no son tan simples.
Yo siempre he pensado que si el arquitecto o la persona que diseño el API no hizo una anotación del tipo runtime fue por algo no solo por magia se debió de pensar que no se necesitaría o que habría un caso que no se debe de permitir, el RetentionPolicy marca los tipos de anotación y si es del class file o de fuente y tu quieres saber lo que dicen esas anotaciones es un problema diferente.
En un mundo perfecto todo estupendo, el problema es la realidad que nos toca vivir, donde por ejemplo el API JPA no permite recuperar todas las entidades que estan mapeadas con un EntityManager, cosa bastante útil, y fíjate si será algo que hace falta que en la versión 2 de JPA lo van a añadir. Pero mientras tanto... ¿nos sentamos de brazos cruzados por que el tipo que hizo el API dijo que no hacia falta?
Y aun incluso en el caso de que la anotación tengo la RetentionPolicy correcta, ¿sabes lo que hace falta para averiguar las clases que tienen una anotación sin tener que cargar una a una todas las clases del classpath? Te aseguro que no es bonito ni sencillo.
Y conste que ni digo que no sirvan y yo mismo uso anotaciones, por ejemplo con JPA, pero algunas cosas para las que se estan proponiendo me parece irse de madre...
En cuanto al lenguaje en sí, de momento está muy muy verde y en Google a veces hacen experimentos por intentar vías nuevas, y no todo lo que hagan va a ser "lo más mejor del mundo mundial", así que de momento no tengo opinión, excepto que el nombre me parece un mal chiste y que hasta que no haya hechos...
Necesito que me respondas algo para poder contestarte.
Explicame que significa esto para usted ya que tengo una idea pero no se si estoy completamente seguro de que sa lo mismo.
@greneyed recuperar todas las entidades que estan mapeadas con un EntityManager
Aclarando:
yo no estoy en contra de la Annotations, estoy en contra de seguir complejificando el lenguaje Java. No, no me niego a que evolucione: tiene que cambiar, pero a mi personalmente me parece que se han incluido aspectos que debieran haberse puesto en otro lenguaje. Creo que en lugar de poner tantas "innovaciones" en Java, Sun podría haber creado Jeve y Jivi (por decir algo): Jeve podría ser el lenguaje de ensayo/pruebas y Jivi sería el definitivo. De este modod Java permanecería simple, sencillo y muy acotado.
Desde el WhitePaper de Java de 1995 (la fecha la digo de memoria) se dice que Java tiene que ser sencillo y simple, y se pone como ejemplo la sobrecarga de operadores y el pre-procesador, rechazándolos porque producen código críptico. Yo, personalmente estoy de acuerdo con lo del pre-procesador, pero no con la sobrecarga. Incluso en las conferencias de Java este verano pasado en Madrid, le pregunté a un compañero de Sun por la sobrecarga de operadores para Java 7, y me respondió con lo mismo que llevo escuchando toda la vida: el código Java tiene que leerse directamente, la sobrecarga de operadores lo hace más críptico y menos legible. Pues si es así, que quiten las Annotations y se las lleven a Jivi, porque no sé de nada menos legible: su mal uso pude producir más confusión que cualquier mal uso del pre-pro o de la sobrecarga de operadores.
Insisto, no estoy en contra de las Annotations, estoy en contra de hacerJava más complejo.
Explicame que significa esto para usted ya que tengo una idea pero no se si estoy completamente seguro de que sa lo mismo.
@greneyed recuperar todas las entidades que estan mapeadas con un EntityManager
Desde el código de tu aplicación, averiguar el nombre de todas las clases que estan mapeadas como @Entity en el classpath para un PersistenceUnit dado. Es algo que, por ejemplo, hace falta en proyectos como OpenXava, donde una librería ha de poder acceder a clases JPA que no se conocen en el momento de escribir la librería.
jbaez: "la verdadera discusión consistiria en plantearse por qué Google ha tomado la decision de sacar un nuevo lenguaje"
Pero es que si hiciéramos eso, rápidamente alguien se daría cuenta de que, tal como dice en la página, Google no ha tomado esa decisión, y que esto es un lenguaje más creado en sus ratos libres por un grupo de desarrolladores que trabajan en distintas compañías, incluyendo (pero no únicamente) Google.
"Noop is a side-project from a collection of like-minded developers and contributers. We hail from several companies, including (but not limited to) Google."
Y claro, si alguien se diera cuenta de eso, todas las teorías sobre estrategias de Google perderían un poco de fuerza y la conversación sería más aburrida... Aunque tampoco veo que nadie haya entrado al trapo con tu teoría de grandiosa estrategia de Google. Uhmm... Igual ya se habían dado cuenta pero no te lo han dicho...
Anonimo
Solo el tiempo dará la razón…
Peyrona, salvo un par de anotaciones el estándar Java no impone el uso de anotaciones concretas, son los frameworks los que usan intensivamente las anotaciones hasta para indicar la temperatura del café.
Si te sirve de consuelo puedes entender las anotaciones como una forma nueva de atributos, por tanto habrá tantos atributos como aplicaciones, y puedes entender la presencia de anotaciones impuesta por los frameworks como una forma de indicarte que tu clase debe tener unos atributos dados con unos valores que tú decides para que el framework pueda leerlos por un get.
En mi opinión "tu enemigo" son los frameworks que hacen uso intensivo de las anotaciones, no las anotaciones en sí mismas, si usas frameworks que controlan/instrumentalizan tu código no hay opción, la instrumentalización busca controlar tu código y limitarte a cambio de en teoría hacerte la vida más fácil, es el problema entre elegir comer en el restaurante o comer en casa, comer en el restaurante tiene la ventaja de que la comida ya está hecha pero tienes muchas limitaciones y si tienes demasiados gustos especiales, requisitos fuertes en calorías o tipos de ingredientes o eres celíaco el restaurante puede no ser la opción, el comer en casa te da mucha más libertad cambio de más trabajo.
La alternativa a las anotaciones es el XML, el problema del XML es que necesita un montón de parafernalia simplemente para indicar qué atributo, método etc es el afectado, dicha parafernalia de localización se evita radicalmente al usar anotaciones. El problema de las anotaciones es que se paga el precio de mezclar aspectos (atributo = almacenamiento en memoria, anotación = información sobre persistencia, serialización, rango, visualización etc).
En resumen, si quieres comer de restaurante te conviene llevarte bien con las anotaciones porque son como el menú, si quieres comer en casa te convendría huir de los frameworks que instrumentan tu código y la mayor razón normalmente de instrumentar es cuando hay inyección de dependencias por medio, por tanto si huyes de las anotaciones has de huir de Spring y EJB 3 y en el caso más extremo de los ORMs modernos (es decir volver al JDBC), aunque los ORMs hacen un uso más "ligero" de las anotaciones pues fundamentalmente son metainformación sobre el almacenamiento y no tanto metainformación sobre comportamiento que es más propio de Spring y EJB3.
Yo soy más partidario de restaurantes en los que puedes entrar en la cocina y hacer sugerencias a los cocineros, este tipo de restaurantes no existen, afortunadamente en el mundo del software sí.
@jmarranz
Como siempre, no puedo por más que estar completamente de acuerdo con usted, compañero. :-)
Permitidme que os pregunte qué opináis sobre otro aspeccto bastante controvertido: la ausencia de herencia. Si no recuerdo mal, cuando leí la web, decían que se admitía composición (lógicamente), pero no herencia. ¿Tenemos OOP sin herencia? ¿Es conveniente? ¿Qué os parece?
Saludos.
Esto es mareante JRuby, Groovy, Scala y ahora NOOP......Es para volverse locos, imposible estar al día.....yo me bajo de este tren que tarde o temprano descarrilará con tanto HYPES , SNOBS y MODERNILLOS subidos en él....que cada día se inventan un lenguaje.....
Por cierto, me encantan las Annotations y la API Reflection por mucho que algunos de vosotros las odieis....
@greeneyed
Lo de saber si una clase esta mapeada en un ambiente de ORM es algo importante eso no lo niego y me alegro que lo incluyan en la especificación 2.0 de java.
Si hubieras hablado del Metamodel impuesto por la especificación JPA 2.0 seria otra cosa ya que este modelo se hizo realidad no para solucionar la carencia de información de las clases si no el typeSafe de las consultas por criterios. Ahora este modelo se desarrollo por la carencia de un Linq en Java ya que dicho modelo puede darnos consultas con tipado seguro y con menos errores pero en mi parecer no es perfecto y se ata a una herramienta de generación de código lo cual no es lo ideal.
En cuanto a Noop y Java
Yo no pienso que la solución sea un lenguaje como Noop debido a que la mayoría de programadores conocen Java y si las ventajas son necesarias seria en Java no en un lenguaje nuevo que hasta el momento es usado solo por un nicho de mercado. Para muestra un botón si vemos a C# que es un lenguaje que ha evolucionado a través de los años, se puede ver que los desarrolladores no se quejan y aceptan los cambios que no son premeditados y tienen un amplio proceso de investigación. Esto lo digo por que en Java muchos cambios lo hace un grupo de expertos que pocas veces están en contacto con la comunidad y están controlados por grandes como IBM, Oracle entre otros y por lo tanto siguen las metodologías de sus propias empresas dañando el lenguaje por su propio beneficio.
Yo pienso que si ampliamos el lenguaje Java y lo hacemos de una manera correcta el impacto seria menor, si vemos el error que sucedió cuando se introdujeron las generics en cuando a que no se puede obtener la información por medio de reflection, si este error se hubiera previsto el gran error que se hizo y la comunidad hubiera participado mas el error en el lenguaje no se hubiera presentado y no habría tantos inconformes con la implementación de los generics.
Ami en vez de ver tantos lenguajes nuevos como Groovy, Scala, JRuby, Jython, Noop, JavaFx, Clojure y sin una especificación que haga que todos estos lenguajes se puedan comunicar a nivel de bytecode no valen de mucho yo prefiero el viejo Java pero evolutivo. Por último si pudiera escoger y Java muriera yo escogería Scala y no Noop aunque el creador de Scala fue el que desarrollo los generics para Java 5 es un excelente lenguaje con tipo fuerte y características funcionales que nos ayudara mucho en la era MultiCore, se que Noop aporta grandes cosas como la inyección de dependencias por medio del compilador y cosas así pero es muy pronto para juzgarlo y tomarlo en serio solo el tiempo dirá que tan bueno llegue a ser.
La verdad es que hasta que no lo has mencionado no me había enterado de que suprimen la herencia de implementación.
Inicialmente me pareció UNA BARBARIDAD.
Ahora bien si lo miras en detalle, realmente lo que ellos hacen es forzar la herencia a través de delegación, generando una interface "de pega" y modificando incluso la clase delegada implementando dicha interface, es decir al final tienes un atributo que tiene SIMILAR rol que el "this", si cambias conceptualmente el "this" por el atributo de delegación al final estás haciendo herencia. Como permiten (creo) que puedas poner explícitamente algún método de los "autogenerados" dichos métodos tienen el rol de métodos sobrecargados. Conclusión: tienes más o menos lo mismo que herencia de implementación, vale.
El problema viene en los detalles:
- Adios a las clases abstractas.
- Mi impresión es que no funciona la simulación de herencia por delegación cuando hay más de una delegación, es decir, el tipo resultante no implementa el tipo inicial en la serie de delegaciones, dudo mucho que puedan asignarse referencias de diferentes niveles de delegación entre sí.
- Es un mero "hack" para evitar código repetitivo, el código repetitivo que cualquier IDE puede generar sin problema, es decir NO aporta ningún paradigma nuevo de programación.
- Me roba una de mis dos armas: la herencia de implementación de verdad. Es decir todo lo anterior está BIEN si ADEMÁS tienes la herencia de implementación de toda la vida.
Pongo un ejemplo real, yo en ItsNat tengo la siguiente secuencia de delegaciones (composición):
ItsNatServletRequestImpl => RequestImpl => ResponseImpl => ResponseDelegateAJAXImpl => ResponseDelegAJAXLoadDocByBrowserImpl
Los CINCO niveles de delegación, tienen, cada uno de ellos, varios niveles de herencia de implementación (y algunas interfases) porque el infierno de tipos de request (carga de documento, eventos, carga de scripts), namespaces (XHTML, SVG, XUL) y navegadores lo exigen.
¿Como coño hago yo eso con Noop o con el nuevo juguete de turno inventado por programadores que jamás han hecho más de mil líneas de código mínimamente estructuradas?
Yo no entiendo qué problema hay con la herencia de implementación, se dice que se abusa de ella (lo dicen los de Noop), yo creo que es mentira, la herencia requiere un tiempo y un esfuerzo de conceptualización, de abstracción, de reutilización, y si tienes a alguien soplándote en la nuca y midiendo tu trabajo por líneas de código y formularios web generados, lo que probablemente no vas a hacer, salvo que ames demasiado tu trabajo y/o el riesgo, es a ponerte a abstraer código plano como árboles de herencia y cadenas de composición, porque dicho trabajo probablemente nadie lo va a valorar y el resultado no va a ser una página web nueva.
Ahora bien, y en esto estoy de acuerdo con remoh, exponer a un programador final un conjunto de clases para que las extienda via herencia de implementación me parece temerario, pero no temerario para el programador final sino para el que hace la clase pues se ata de pies y manos.
Esta discusión ya la tuvimos antes, recuerdo que remoh hacía referencia a un enlace de JavaWorld "Inheritance considered evil", Cedric Beust, bastante conocido por TestNG, hace su crítica de aquel artículo con el divertido título de ""Inheritance considered evil" considered evil".
jeje, ya volvemos a lo interesante xd
- Adios a las clases abstractas.
pues hasta luego, que tanta paz lleven como descanso dejan, con interfaces y composición, y más aun con mixins, no hacen ninguna falta.
- Es un mero "hack" para evitar código repetitivo, el código repetitivo que cualquier IDE puede generar sin problema, es decir NO aporta ningún paradigma nuevo de programación.
Es que no es un hack, se propone composición como alternativa soportada por el lenguaje para obtener reutilización y polimorfismo por una via alternativa a la herencia de implementación, y claro que no es ningún paradigma nuevo, es orientación a objetos normal y corriente, pero quitando lo que no les gusta.
¿Como coño hago yo eso con Noop o con el nuevo juguete de turno inventado por programadores que jamás han hecho más de mil líneas de código mínimamente estructuradas?
Coño tampoco es eso, porque no te guste el enfoque no eches mierda encima de esta gente que tampoco les conoces de na xd (bueno eso creo, si tienes más datos...). Y claro que es un juguete, de momento no es más que eso, pero esta bien experimentar con nuevas cosas y no cerrarse en que el camino que uno sigue es el único viable, así no avanzamos nunca, en 30 años es probable que ni estemos usando OO y no se habra acabado el mundo. Y como dije la otra vez, en nuestro desarrollo tenemos más de 60.000 lineas de código (no cuento las de test, con estas el doble aprox), no usamos herencia de implementación nada más que para heredar de httpservlet y porque no queda otra, y no es perfecto, pero tampoco es mal código.
Quizas todo dependa de los problemas con lo que se ha encontrado uno, yo vengo de un entorno con cuatro o cinco programadores donde la herencia de implementación nos ha traido bastantes disgustos, por usarla mal evidentemente, pero también porque permite romper muy facilmente la encapsalución y guarrear cosa fina. Si tu trabajas tu solo, te conoces tu código, y eres minimamente ordenado pues no dudo que con la herencia de implementación hagas buenas cosas, pero tampoco creas que ese es el único camino. No se, ponme un ejemplo de algo que hagas con herencia y con composición veas imposible. (uno facil, que estoy de medio-vacaciones xd)
Aún así, para clases internas de un framework que estén todas bajo tu control, tampoco me parece un crimen la herencia de implementación, pero si puedo evitarla la evito, y de momento he podido sin mucho problema. De todos modos no es esta la caracteristica que más me interesa de noop, me quedo con la DI como parte del lenguaje y sobre todo con el enfoque a testing, un lenguaje que considere el testing y generar código testeable (es que "probable" suena raro xd) como parte importane de su diseño me parece un paso adelante, o al menos un experimento que trata de dar un paso adelante, en la dirección adecuada.
>en nuestro desarrollo tenemos más de 60.000 lineas de código
Bueno, si usaras herencia seguro que tendrías muchas menos líneas de código :-D.
Es una broma, de repente de mal gusto ...
Saludos
Para mi las clases abstractas son *extremadamente* útiles como forma de establecer un contrato de la clase base con las clases derivadas, sin ellas tendría que inventarme montones de interfaces tontorronas.
Coño tampoco es eso, porque no te guste el enfoque no eches mierda encima de esta gente que tampoco les conoces de na xd (bueno eso creo, si tienes más datos...).
Reconozco que me estaba riendo cuando escribía eso, tendría que haber puesto un :) Era una exageración, me consta que esto no lo van a leer los pobres, de otra manera no sería tan radical :)
Pero en lo que sí me reafirmo es que hay algo de estúpido en inventar un lenguaje basado en la JVM en donde la capacidad de tener herencia de implementación está soldada en el mismo bytecode y en la JVM (es decir no es algo que proporcione Java y desaparezca al compilar) y que por un prejuicio sencillamente te la cargues.
Una cosa es una opción personal como la tuya y tu equipo, otra cosa es ofrecer algo al gran público eliminando una de las herramientas más importantes de la programación supuestamente porque "se abusa", es como prohibir el vino porque existen alcohólicos, puritanismo paternalista llevado al software.
Pero lo curioso es que no es que se quite del todo, encima se sigue ofreciendo la herencia de implementación a través de una forma descafeinada (sin clases abstractas), problemática (posiblemente no es posible asignaciones entre referencias de varios niveles) y forzada (implementando interfaces fantasma etc).
remoh: donde la herencia de implementación nos ha traido bastantes disgustos, por usarla mal evidentemente, pero también porque permite romper muy facilmente la encapsalución y guarrear cosa fina
Yo no conozco vuestro caso, pero si alguien hereda de una clase tiene la obligación de conocer qué es lo que hay encima, y si alguien modifica una clase base, tiene la obligación de conocer qué es lo está debajo, por una cuestión ontológica, la herencia responde al "qué soy" si la cambia la clase base estoy cambiando el "qué soy" por lo que las clases derivadas, que construyen su identidad a través de extensión/modificación de la "identidad" de la clase base, pues obviamente tendrán algún problema psicológico que es necesario tratar, es lo que se llama psicología de la herencia (tontería que me acabo de inventar). Con los IDEs actuales es relativamente fácil conocer el impacto de lo que estás cambiando con el "Find Usages" y similares. Por no hablar de que a la hora de dividir el trabajo quizás convenga dividir modularmente las cosas y no que todos toquen todo.
remoh: No se, ponme un ejemplo de algo que hagas con herencia y con composición veas imposible.
En este mundillo no hay nada imposible, recuerda que al final todo se convierte en código espaguetti lleno de ifs y gotos.
En el ejemplo que te ponía hay 5 clases en composición sucesiva en donde hay herencia de implementación en cada eslabón con varios niveles. Si hay 5 niveles de composición (bueno 4 composiciones para ser estrictos) es precisamente para evitar un abuso de la herencia de implementación. En cada eslabón tengo claro que hay una instancia por lo que al final manejo 5 instancias encadenadas, si substituyo la herencia de implementación, que en alguno de los eslabones puede llegar a unos 4 niveles, por herencia a través de composición, pues me encuentro con que puedo llegar a tener que manejar unas 15 instancias considerando como media tres niveles de herencia. Si ya con 5 instancias me hago la pi**a un lío imagina con 15. Y todo por un capricho de unos chicos simpáticos de Google. Lo siento pero NO.
Respecto a si seguiremos usando la OOP en el futuro... pues ni idea, pero la Historia del software es muy puñetera y normalmente pasa factura a las "simplificaciones buenas" que aportó Java respecto al C++:
* El primer Java no tenía generics. Pues toma generics. Pero claro el objetivo no era hacer generics como en C++ sino algo más light que desaparecieran en tiempo de compilación, bien pues ahora todo el mundo se queja de que los generics son un apaño y que tendrían que haber sido generics como Alex Stepanov manda (el creador de las STL de C++), es decir generando tipos nuevos a nivel de bytecode.
* El primer Java no tenía herencia de implementación múltiple. Ahora la gente de Scala pone de moda los traits que son una forma de herencia de implementación múltiple.
* Java no tiene sobrecarga de operadores. No hay problema, ya se encargan los de C# en introducirlos como una ventaja competitiva que algunos agradecen y Scala los introduce también.
* Java no tenía instrucciones de precompilación (los ifdef y esas cosas) y generación de código (macros). Pues toma anotaciones, una forma de metaprogramación que algunos frameworks usan para inyectar bytecode. Toma lenguajes como Noop que generan código a través de nuevas palabras clave.
* Java metió la gestión de hilos en el lenguaje (synchronized) en vez de usar APIs como en C/C++: pues toma APIs de concurrencia.
Si Scala es el futuro (eso parece salvo que evolucione Java) tenemos OOP y herencia de implementación para rato.
Pues a mi me encanta la herencia. Hace falta pasar un rato tomando cocacolas y pensando antes de empezar a tirar lineas, pero si se piensa *bien* en como se van a hacer las cosas y como pueden evolucionar, usar herencia te permite ampliar el proyecto en un futuro sin muchos problemas.
Ni es perfecta ni sera el ultimo paradigma que se use (aunque personalmente creo que durara mas que los aspectos y la composicion de la que hablamos ahora) pero creo que los problemas que se le achacan no aplican en el mundo real.
El problema de la herencia es que yo tengo una clase A, escribo mi clase B heredando de ella, despues me cambian las tripas de A y B deja de funcionar. A ver, si A es mia, es responsabilidad mia prever el efecto de cambiar A, y segun cambio A cambio B. Y si A es de otro (un framework, otro departamento...), pues meter la nueva A es un cambio de version de una libreria, que aunque se suela tomar a la ligera (sobre todo desde que existe maven) no es una cuestion en absoluto trivial y se tiene que hacer con cuidado. Y a las malas, quedarse con la version vieja de A hasta que se modifique B. En cualquiera de los dos casos, el que esta mal hecho es B, no A.
Lo mejor es no cambiar A, lo que cual es un problema porque "ata" al que hace A, pero si no queremos que A este atado, pues liberemosle tambien de mantener el interface... ¿O es que al que hace A hay que darle libertad para cambiar la implementacion de forma radical (un cambio peuqeño no va a hacer que B deje de funcionar) pero no para cambiar el interface? Si liberamos al de A, le liberamos.
El problema de la herencia es un problema que entiendo, porque la misma Sun me la jugo una vez cambiando las tripas de un componente de Swing (seguro que por una buena razon) y tuve que cambiar un desarrollo mio (que tampoco andaba muy fino, la verdad) para que siguiera funcionando, pero habria sido peor no tener herencia y haber tenido que reimplementar cientos de metodos.
Remoh, puestos a buscar ejemplos, imagina que quiero hacer una modificacion a cualquier control de Swing (me encanta Swing), sabiendo que todos heredan de JComponent y que JComponent tiene una lista larguisima de metodos. Si heredo, cambio lo que necesito. Si compongo, los tengo que reimplementar todos. Por ejemplo, un combobox de esos que tienen los navegadores, que te sacan mil opciones y segun vas escribiendo se van reduciendo hasta que le das a la flechita para abajo, al enter, y ya estas en youtube despues de escribir solo "tub".
A mi me perece muy bien que se creen lenguajes nuevos para tener estos experimentos, pero Java que lo dejen tranquilo, que bastante follon hay ya con los closures (¿aportan algo a las inner classes a parte de para ahorrar unas lineas de sintaxis?) como para meter mas ruido.
Y POO tiene herencia. Por definicion. Si no se quiere, no se usa, pero si no hay herencia, no hay POO. Hay otra cosa.
nilojg: que bastante follon hay ya con los closures (¿aportan algo a las inner classes a parte de para ahorrar unas lineas de sintaxis?)
Qué razón tienes, que conste que yo sí quiero closures pero para que quede más bonito nada más no me aportarán nada nuevo funcional, yo creo que cualquiera que haya usado intensivamente Swing, en donde se suelen usar inner clases constantemente, no entiende el debate de las closures como la gran decisión del futuro de la humanidad.
La verdad es que me has recordado otro punto de simplificación "guay" que introdujo Java respecto a C++: la supresión de los punteros a función. Primero vimos la API java reflection que se introdujo en Java 1.1 (no estaba en la 1.0) y ahora estamos discutiendo sobre closures cuyas referencias son una forma de punteros a función.
En fin todo cambia para que nada cambie pero a la vez sea todo diferente.
nilojg: "Y POO tiene herencia. Por definicion."
Díselo a Alan Key. A lo mejor se pone a contarte algo sobre la definición de POO, pero siempre puedes ignorarle, porque está viejo y seguramente no sabe de lo que habla.
El problema de la herencia no es que te cambien una clase o que uses las clases abstractas para esto o lo otro. El problema es que ni el mundo real funciona así, ni nuestro cerebro funciona así. Principalmente lo segundo. En nuestro cerebro, dependiendo del contexto en el que estemos pensando un B puede ser o no ser un A y a veces incluso dentro de un mismo contexto.
Así, en contextos muy claros y delimitados es más o menos fácil crear una jerarquía de relaciones de herencia, pero en cuanto el contexto no está tan claro, en cuanto cambia algún pequeño detalle o en cuanto el contexto es un poco más amplio, entonces es cuando surgen las inconsistencias y cuando hay que trabajar con relaciones de herencia que simplemente no resultan naturales. Ojo, no quiere decir que no puedan funcionar, sólo que no son naturales y por ello terminan siendo necesarios esos cambios, ajustes y compromisos.
El creador de Scala fue uno de los que desarrollo generics en lenguajes tipo Java y era una implementacion mas sencilla. http://pizzacompiler.sourceforge.net/, http://www.cis.unisa.edu.au/~pizza/gj/, http://www.cis.unisa.edu.au/~pizza/gj/Documents/. La mayoria de esto se desarrollo bastantes anios antes de acabar oficialmente en Java (en Pizza y GJ), y lo que acabo en Java 5 es ... otra cosa.
Pues reconozco que he tenido que buscar en la wikipedia a Alan Kay, pero, a parte de que el parrafo que copias creo que esta fuera de lugar porque, en informatica, siempre se tratan "contextos muy claros y delimitados" porque si no es asi no se pueden modelizar (convertir en 1s y 0s, vamos). Asi que en informatica el mas o menos facil crear una jerarquia de relaciones de herencia.
Pero me ha parecido muy interesante leer sobre el porque a mi tambien me interesan mucho los interfaces graficos. Uso mucho Swing y concretamente en el caso de Swing, no me imagino la pesadilla que seria programar una aplicacion Swing sin herencia. Me imagino poner botones y combos sin herencia, claro, pero eso no seria Swing, si no una especie de formateo HTML de Java.
Gracias a la herencia en Swing puedo hacer una ventana trasparente, un panel con un fondo degradado o una imagen de fondo, un combobox como el que describi en mi comentario anterior o un checkbox que se activa con una animacion de un enanito que sale de una seta reescribiendo solo uno o dos metodos de cada componente.
Una mejora importante. Y no me meto en lo que no es presentacion porque la chicha de cada aplicacion es de esa aplicacion y no puedo poner ejemplos que cualquiera pueda comprobar. Lo guay de los ejemplos de Swing es que estan a un javadoc de distancia.
jmarranz, yo lo que mas echo de menos es liberar la memoria cuando quiero. Tambien la sobrecarga de operadores, pero mas liberar la memoria. Puede ser pesado recordar hacer free, pero lo hecho un monton de menos.
Y es verdad, yo no entiendo el debate de los closures porque para mi es una abreviatura de las inner clases.
nilojg: hay una línea de separación que indica que lo que viene después deja de ser una contestación a ti y pasa a ser algo más general. No hay ningún párrafo copiado fuera de lugar, es una opinión (a no ser, claro, que creas que mi opinión está fuera de lugar). La contestación a tu frase, la que he citado, es sólo las primeras dos líneas que he escrito.
la Historia del software es muy puñetera y normalmente pasa factura a las "simplificaciones buenas" que aportó Java respecto al C++:...
Si Java hubiera empezado con todas esas cosas "guays", a estas alturas no se en que estaríamos programando pero en Java seguramente no. Cuando Scala y demás sean tan populares y usados como Java, entonces hablamos de lo bien que está un lenguaje con esas cosas.
otro punto de simplificación "guay" que introdujo Java respecto a C++: la supresión de los punteros a función.
Falso. Java eliminó la aritmetica de punteros. Los punteros siguen existiendo y los punteros a función no son más que un atajo de lo que puedes hacer de forma más verborreica con inner clases, o antes sin que fuesen anónimas. Pero la intención no fue nunca eliminar los punteros a función, si no los peligros de la aritmética de punteros.
Debe ser que sólo algunos, como Peyrona que se lo he oido comentar, recordamos que una de las características principales de Java, y hecha a conciencia, fue su simplicidad y, IMHO, fué una de las cosas que le permitió alcanzar el éxito que ahora tiene. No vamos decir que lo hicieron perfecto y no se podría haber hecho mejor, pero ahora "todo el mundo" tiene su opinión sobre como lo habría hecho mejor, lo "fácil" que es evolucionar un lenguaje con millones de desarrolladores por todo el mundo donde miles de empresas se juegan el cuello... claro, desde el sillón de su casa.
Y como dicen, las opiniones son como el agujero del culo, todo el mundo tiene uno, cree que el suyo es la caña y que el de los demás apesta.
Yo sólo digo: Java y Sun ya han demostrado con hechos a donde se puede llegar con las decisiones que tomaron, el resto son elucubraciones y programas compilados en PowerPoint hasta que demuestren lo contrario.
Entonces, lo siento, pero es que como la gente mete toda clase de marcado para citar y dentro de lo que cabe, estaba dentro del tema... Lo siento.
greeneyed: Si Java hubiera empezado con todas esas cosas "guays", a estas alturas no se en que estaríamos programando pero en Java seguramente no.
Estoy de acuerdo, sólo quería constatar que el marketing del "no incluido=bueno" a veces da la vuelta.
Yo no he dicho que no existan los punteros (estaría bueno), lo que no existen son los punteros a función, lo cual tiene poco que ver con que haya o no aritmética de punteros. Es decir yo no encuentro algo así en Java:
class Prueba
{
public static void mostrar(String msg) { System.out.println(msg); }
public static (void (String)) getMostrar()
{
void (String) pf = &mostrar(String);
return pf;
}
public static void saludo(void (String) pf)
{
pf("Hola");
}
public static void saludo()
{
saludo(getMostrar());
}
}
Lo de antes es un invento inspirado en los punteros a función de C.
Los closures vienen a ser algo parecido a lo anterior aunque más bien orientados a la captura del contexto en el ámbito de un bloque de sentencias más que a representar métodos de la clase, aunque no dejan de ser una especie de punteros a función.
Yo personalmente no soy partidario de evolucionar a lo tonto Java, hay una presión por meter mini-comportamientos en el lenguaje que perfectamente pueden estar en una API, estándar o no, presión que yo creo que hay que evitar. Yo creo que cuantas más palabras clave tiene un lenguaje peor diseñado está.
ricardo: Bueno, si usaras herencia seguro que tendrías muchas menos líneas de código :-D.
Algunas menos si tendriamos, porque usando delegación te ves obligado a delegar todos los métodos uno por uno, lo hace el IDE solo aunque no es la mejor solución, un IDE puede ocultar la complejidad o generar código automatico, lo que no puede es justificar la presencia de ese código, precisamente ese el problema que ataca noop, evitar esas lineas innecesarias haciendo de la composición un constructor del lenguaje. Pero vamos tampoco son muchas más si defines interfaces pequeños y con responsabilidades bien acotadas. Como todo es poner las cosas en una balanza, prefiero escribir alguna linea de más y usar composición, cada uno que elija.
jmarranz:
Basicamente nuestros problemas con la herencia (en C++ por cierto este desarrollo, pero para el caso es lo mismo) venian por el uso y abuso de "protected", la jerarquia era bastante coherente y no estaba nada mal diseñado, la ves sobre el papel y dices "buen diseño muy coherente". El problema estaba en muchos detalles de implementación donde la clase base declaraba tal propiedad "protected" y luego esa propiedad se modificaba en una clase hija dos o tres niveles hacia abajo en la jerarquia. El problema esta claro que es nuestro y no de la herencia en este caso, pero cuando el código crece y se modifica entre varios las cosas tienden a descontrolarse a poco que no tengas cuidado, y la herencia permite demasiadas cosas peligrosas en estos contextos, así que la evito siempre que puedo.
Por no hablar de que a la hora de dividir el trabajo quizás convenga dividir modularmente las cosas y no que todos toquen todo.
En esto si que no estoy muy de acuerdo, no me gustan los equipos dividos por modulos/componentes, me gusta que todo el mundo toque todo, y no hay ningún problema si tienes una bateria de test que te aseguran que despues de cambiar algo todo sigue funcionando (por cierto la herencia de implementación, como toda forma de acoplamiento entre implementaciones y no interfaces, es muy poco amiga de los test unitarios). Y consigues que todo el equipo sea capaz de tocar cualquier parte del código, y disminuyes el factor "camion", este factor viene determinado por el número de miembros de tu equipo que pueden ser atropellados por un camion y que el proyecto no se venga abajo :P (si tienes factor camion 1, es decir, si atropellan a fulano esto no hay quien siga con ello, entonces tienes un problema). Propiedad colectiva del código que dicen en XP, ya sabeis que me gustán estas cosas de los agilismos xd.
niloj:
El caso de swing es un poco particular, no te queda otra que usar la herencia porque swing esta diseñado para ser extendido de este modo. La cosa es si se podría diseñar un framework de componentes graficos sin usar herencia, sería una buena prueba de fuego para la composición intentar algo así, pero no conozco lo suficiente swing para saber si seria posible la verdad. Seria un buen reto para los de noop "ahora con ese lenguaje nos diseñais una librería de componentes visuales" :P
Aunque ya pensando un poco, se me ocurre el caso de ExtJS o otros frameworks JavaScript, en js no hay posibilidad de tener herencia de implementación, ExtJS por ejemplo utiliza un mecanismo simulado de herencia que se parece más a la propuesta de composición noop que a la herencia de implementación normal (es "instance based" por defición al ser js). Y no es swing, pero es bastante completo y muy extensible.
Muy interesante. Poco más que aportar porque lo habéis dicho todo, pero por resumir un poco diré
1) Si ves la Herencia como mecanismo de reutilización de código perse, terminarás en un infierno del tipo que comentais: gente que toca alegremente y rompe el trabajo de los demas. Pero...
2) La Herencia como mecanismo de especialización/generalización (que implica reutilización de código) es una genialidad que se aplica de forma natural dando diseños geniales y código muy limpio. Ver Patrones de diseño de Erick Gamma o Swing, por poner unos ejemplos...
Cargarse la Herencia para hacer un lenguaje específico no me parece pecado. Yo en mis aplicaciones raras veces la uso, al contrario suelo tener que corregir el uso que le da otra gente por composición. Pero Java es un lenguaje de propósito general y uno de sus usos es crear frameworks. Quítales la herencia a los de Swing y habrá mas suicidios que en Telecom.
A parte de que quitar la herencia deja muy tocado el principio OO de Abierto-Cerrado. El hack que proponen en realidad no deja de ser un hack y sigues teniendo el problema de que si alguien te toca la clase componente te trastoca todo.
Yo alucino.....toda la vida practicando y aplicando el tema de la herencia a la POO y ahora resulta que no es recomendable.....APAGA Y VAMONOS......El desarrollo del software se hunde señores!!! Quiero volver a los 80's cuando todo era más facil.....Si por ejemplo queria aprender PASCAL visitaba la biblioteca y cogia prestado "La Biblia de Pascal" y si queria aprender C la "Biblia de C" y en esos libros estaba TODO (o casi). Ahora resulta que para aprender JAVA no basta con "La Bliblia de Java", necesitas STRUTS, SPRING, HIBERNATE y la p**** en vinagre.....En caso negativo NO SABES JAVA.....Nos estamos complicando la vida....yo apuesto por una autentica revolución, volvamos a los inicios y formemos un grupo de RETRO-PROGRAMADORES!!!!!!! Los clasicos nunca mueren LONG LIVE PASCAL!!!!
Firmado: MrFishKill
nilojg: no problemo. sólo lo aclaraba.
Para completar: Se saben aquel que dice que está James Gosling en una conferencia...
During the memorable Q&A session, someone asked him: "If you could do Java over again, what would you change?" "I'd leave out classes," he replied. After the laughter died down, he explained that the real problem wasn't classes per se, but rather implementation inheritance (the extends relationship). Interface inheritance (the implements relationship) is preferable. You should avoid implementation inheritance whenever possible.
Esa cita ya la use en la anterior discusión sobre el tema jeje. Jmarranz cree que james fue bebido a la conferencia, algo no descatable en todo caso xd
A mí lo que me parece fascinante de estas discusiones es lo fácilmente que la gente es capaz de "cambiar de bando" en función de sus gustos. Por ejemplo: "La característica X puede ser abusada por los programadores, así que vade retro! debería ser eliminada" y un poco más tarde "No, no, la característica Y es bueníiiiisima y aunque se puede abusar de ella, se puede abusar de todo y es responsabilidad del programador saber utilizarla; además si no te gusta no la uses".
Todo un tratado de la disonancia cognitiva :)
greeneyed: Todo un tratado de la disonancia cognitiva :)
No, más bien has hecho un resumen de dos actitudes vitales: restriccionistas (no me sale otra palabra) y libertarios :)
Sí y no. Sí son dos actitudes vitales pero son "opuestas" y yo estoy hablando de cuando se da esa misma actitud en la misma persona al misma tiempo en temas parecidos. Es entonces cuando se pone en marcha la disonancia cognitiva para buscar "escusas" que siempre justifican el "pero es que en este caso no es lo mismo".
Y ojo que no es un insulto ni nada malo, a priori si no dejas que te ciegue, es la naturaleza del ser humano y nos pasa a todos.
¿Pondrán Diseño por Contrato en Noop? Estaría bien
Os rogé que me diéseis vuestra opinión sobre el hecho de que en NOOP se hayan planteado no incluir herencia y he pasdo muy buen rato leyendo los cometarios de todos. Muchas gracias a todos.
Saludos.
Pues al comentario de remoh del 22/09/2009 17:15, podróa contestar rugi a la frase:
"El caso de swing es un poco particular, no te queda otra que usar la herencia porque swing esta diseñado para ser extendido de este modo. La cosa es si se podría diseñar un framework de componentes graficos sin usar herencia, sería una buena prueba de fuego para la composición intentar algo así, pero no conozco lo suficiente swing para saber si seria posible la verdad. Seria un buen reto para los de noop "ahora con ese lenguaje nos diseñais una librería de componentes visuales" :P"
¿Qué opinas Rugi? Se podría hacer Swing sin usar herencia. Lo pregunto ya que tú has trabajado con swing durante bastante tiempo, es tu karma. :D
Escribe tu comentario