herencia multiple en php5
 

¿Alguien conoce algun "truco" para usar la herencia multiple en php5?
Gracias de antemano
paloclanweb

No soy el gurú de objetos, pero Java, hace más de 10 años que trabaja con objetos y no acepta herencia múltiple. Por algo será no?

Una pregunta... PHP5, no podés hacer una interface como en java?, es una forma que se me ocurre.

SALUDOS!

a ver si te sirve esto:
http://www.desarrolloweb.com/articulos/2197.php

saludos

si, php sigue casi la misma filosofia de JAVA, asi k si sabeis JAVA, pos podes hacer lo mismo, usa una interface.......

quien dijo que java no acepta herencia multiple?? es una broma?

echale un ojo a este link http://www.desarrolloweb.com/articulos/2026.php

Gracias a todos...realmente php 5 no permite herencia multiple ...la solucion es utilizar interfaces
Saludos

SiR. Carajodida: Java no utiliza herencia multiple (fijate en cualquier manual, tutorial, etc). Lo que se utiliza es Interfaces. Igual PHP5.

Ja, me encantan ésas indirectas.

...pero C++, hace más de 15 años que trabaja con objetos y sí acepta herencia múltiple. ¿Por algo será no?

Y ya no te digo lenguajes más antiguos...

Qué manía estos de Java, de decir que si algo existe es que es usado.

Si no quieres herencia múltiple, no la uses. Pero mejor tenerla que no poder usarla, ¿verdad?

paloclanweb, ánimo con tu uso de la herencia múltiple, si es que encuentras la manera de hacerlo funcionar (aunque lo dudo).

Las interfaces, a mi parecer, no aportan la misma funcionalidad que la herencia múltiple, son conceptos distintos.

Por ejemplo, C++ tiene interfaces (clases abstractas puras que se llaman en realidad) y herencia múltiple y se usan para cosas diferentes.

Por lo que he visto en varios lenguajes, la discusión legítima no es "si se puede hacer o no". En muchos casos no se implementa (como en Java, PHP, etc) porque usarla es un posible camino al desastre.

Verdaderamente no es problema técnico, o de evolución, es un problema de criterios de diseño "OO".

De todas formas siempre hay una puerta trasera: hacer "herencia múltiple" a través de interfaces; pero el sentido es distinto a hacerlo con clases. Las herencias de clases definen el "que son" y las interfaces agrupan clases que definen el "que hacen".

Y finalmente, las interfaces permiten pasar del estilo de diseño "orientado a la implementación" a uno "orientado a la interfaz", donde todas las clases acceden a servicios a través de interfaces que son implementadas por clases concretas. Y al no depender de clases concretas (solo de entidades abstractas) nuestro diseño será más reutilizable que el anterior.

Al final de cuentas, todo es una discusión de diseño OO ;-)

Me parece que se está transformando en una discusión filosófica y lo importante sería PHP5 no implementa herencia multiple.
Porque sino vamos a terminar hablando de SmallTalk :)

SALUDOS.

PD: MaxExtreme, my buena respuesta, más allá que estabas ironizando también con mi mensaje.

PD2: Dejo otra reflexión, los desarrollos en JAVA, no funcionan tan bien en Windows, por algo será no? jejejeje

C++ existe hace 20 años y logró implementar la herencia múltiple de una manera eficaz.

Java no lo hace pora poder simplificar un poco el modelo de objetos que tiene. Y en realidad Java implementa una pseudo herencia múltiple, con Interfaces.

Saludos

perdon pero no entiendo, en java nose puede hacer esto?

lo veo en todos lados, acaso eso no es herencia multiple??

no, eso es un arbol de herencia. Para que fuese herencia multiple deberia ser algo asi:

public class A {//...}
public class B {//...}
public class C {//...}
public class D {//...}
public class E extends A,B,C,D{//..}

Java esto no lo permite.

Bueno, su predecesor es de 1983, hace 23 años, pero no tenía prácticamente nada como tiene ahora.

El comité C++ salió allá por el 1990, y se empezó a implementar después.

Pero el primer estándar verdadero ISO salió en 1998. Luego otro en 2003, y por último saldrá otro en el 2010.

Java no lo hace porque no lo han visto esencial, por ahora, pero puede que lo añadan en un futuro. Java no para de cambiar. Lo cual no quiere decir que no deban implementar la herencia múltiple, que es MUY útil.

El primer argumento que has usado es el que más odio xD: "Como es complicado, no lo soporta el lenguaje". Si es complicado, o no te atreves con ello, no lo uses.

Pero tampoco conduzcas, no sea que te estrelles, o no salgas a la calle, que hay bacterias. ;) Las cosas como son: Es mejor tener que no tener, que sobre, que no que falte. Al menos, es mi punto de vista.

Como Java soporte algún día la herencia múltiple, voy a reirme mucho xD Yo no suelo usar herencia múltiple, pero QUIERO que esté abierta la posibilidad.

La excusa de "no está porque es un desastre" no es válida. Si existe la herencia múltiple es porque hubo gente que la vió útil.

Por otro lado, C++ soporta "interfaces", que no son más que clases abstractas puras en realidad, así que existen las dos opciones.

En C también puedes implementar interfaces. No son más que listas enlazadas que contienen estructuras que indiquen la dirección de memoria de cada función, los parámetros y el tipo de retorno (por poner un ejemplo). Se usa bastante cuando se trabaja con DLLs y plugins. Es código sucio, pero como en Java, no es más que "trucar" el asunto :P

No, eso son varias herencias simples, como bien dice Tolaware.

En C++ se implemente así:

Eso podría significar, en un videojuego multijugador, que hemos definido un objeto llamado "Silla", que tiene asociado un modelo 3D, que es destructible, y que se calcula en el lado del cliente (porque es decorativa y no afecta a la jugabilidad así que el servidor no tiene que manejarla).

Es una forma de programación muy útil si se sabe controlar. Si no sabes bien las reglas de la herencia múltiple (mucho más complejas que la de la simple, debido a la cantidad de "peros" y "qué-pasa-sí", constructores, destructores, ...) es un CAOS.

Soy algo puntilloso cuando contesto :P

En teoría deberían funcionar igual, ¿no? Ups, no, depende de la máquina virtual y de los cafés que se dejaron de tomar los de GNU/Linux/Microsoft/Sun cuando trataban de implementar todo el J2XX.

aa ahora entiendo, siempre entendi que herencia multiple era eso, pero en mi opinion no estaría bien eso, es como si una clase tuviera varios padres y eso no tiene sentido... nose, es mi humilde opinion, soy newbie en java :P

Eso es hacer "múltiples herencias", no "herencia múltiple". ;-)

La herencia múltiple sería:

class C extends A,B{
}

Donde la clase C hereda atributos y/o métodos de dos clases o más.

Por ejemplo, la clase "HombreLobo" puede heredar de la clase "Hombre" y de la clase "Lobo", pero el problema es que se pueden hacer tantas combinaciones que es difícil de seguir y mantener un diseño de este tipo. Por eso muchos lenguajes no la implementan, no por un tema técnico, solo por un tema de salvaguardar la integridad del diseño.

Los problemas más comunes son las "colisiones de nombres" y la "herencia repetida".

Y ya que estamos, comento: en las guías de diseño recomiendan que para una buena jerarquía de herencia:

- Deben tener no más de 7 (+-2) niveles
- Las jerarquías "gordas y bajas" son síntoma de "poca especialización"
- Las jerarquías "altas y flacas" son síntoma de "excesiva especialización".

El tema es no abusar de la herramienta.

en que basas tu opinión SIR?

Me he visto en varias situaciones en Java, en que he necesitado a gritos la herencia multiple y ha sido en esos casos en que he extrañado a C++.
No explico que situaciones, porque son problemas tecnicos muy especificas de una apliciacion.

Bueno, el ejemplo que te he puesto antes es perfectamente válido.

Por ejemplo, yo uso herencia múltiple en muchos proyectos, tantos como haga una clase que no tenga que ser copiable.

Defines una clase base que no permita su propia copia. Luego, de ahí heredas para que la hija adquiera ese comportamiento.

Por ejemplo, defino una clase "ServidorFTP". No tiene sentido copiar la clase de un servidor FTP, por tanto, le define así:

Y ya no puede ser copiado nunca. Esto, será añadido en C++0x.

La librería Boost ya lo implementa. La clase "Noncopyable" sirve para eso.

En poco, porque ni sabía que existía... :P

Lo extraño asusta, pero no por ello es malo.

No abusar, pero sí poder usarla.

Y bueno, no opino lo mismo. Será el programador el que tenga que salvaguardar el proyecto, no el lenguaje. Por esa regla de tres, programemos en un Basic.

Los problemas se pueden evitar, si se sabe hacer. Pero hay que aprender claro.

En verdad, lo que ocurre es que para usar herencia múltiple hay que pensar bien las cosas antes de escribir nada, porque luego no hay vuelta a atrás.

En cambio, con la simple, la gente lo ve como algo "más o menos fácil", y aún así, como no diseñes bien la aplicación, la has fastidiado.

Los problemas más complejos vienen en el seguimiento del código, entender qué se está ejecutando antes y qué después, el seguimiento de la memoria, los punteros, que van y vienen entre clases y hay que reservar y liberar correctamente, no tener objetos duplicados, no perder rendimiento, etc.

Sobre el lenguaje, todos tienes reglas distintas y distintas formas de atacar los problemas. Siempre existen limitaciones técnicas y no-técnicas, por eso optamos por uno u otro lenguaje.

Con respecto al tema de "herencia múltiple", no es una sugerencia personal, lo dicen los grandes autores de grandes libros ;-)

... tampoco bueno ... por eso es bueno leer, adquirir conocimiento, razonar, cuestionar, acumular experiencia para luego poder decidir por nosotros mismos.

Conozco pocos programadores que leen o estudian materiales sobre diseño, principios y guías sobre Orientación a Objetos.

Programar orientado a objetos es fácil, hacer un sistema reutilizable y con bajo costo de mantenimiento, difícil (todo un arte, diría).

Son de esos "grandes autores" de los que hicieron que fuera posible que existiese y promoviesen la herencia múltiple en su día. Que ahora vengan algunos a criticarla algunos "nuevos gurús", es otro tema.

No leamos sólo a los autores que nos interesan :)

Por otra parte, muchos grandes programadores que no salen a la luz con libros, que trabajan detrás del escenario, programando fundamentalmente compiladores y sistemas operativos, tienen mucho que decir, y seguramente puedan opinar mejor ellos que un miembro del comité de estandarización de "X" lenguaje.

Pero en la vida todo depende de la situación, no de la capacidad de las personas ;)

Ahí te doy 100% apoyo.

Conozco a muchos programadores, pero pocos lo son.

Muchos se autoproclaman programadores de tal lenguaje, tecnología, metodología, paradigma (no sólo POO)... y no lo son ni de lejos.

Hoy en día ser programador es muy fácil, hay críos de 10 años que programan. Por tanto, son "programadores".

En cambio, encontrar personas que lleven o hayan llevado el tema de un kernel, de una aplicación ofimática, de un engine3d o proyectos de similar importancia en otras categorías, casi imposible si no les buscas expresamente.

Supongo que ocurre en cualquier materia de la vida, pero en la programación, ha sido tan simplificada hoy en día (sobre todo con la aparición del dios-VB6), que parece que ser programador es ser tonto, puesto que te comparan con niños de 10 años. Lógico. Es como si ahora los niños de 10 años saben integrar porque usan Derive o Mathlab.

¿Quién promueve la herencia múltiple? (¿autor, libro?)

Sobre los "nuevos gurues", te equivocas, hablo de los viejos. Libros como el GOF, escritos de Martin Fowler, etc. El nuevo testamento y los apóstoles de la OO.

Te doy un ejemplo sencillo: ¿dime cual patrón de diseño utiliza la "herencia múltiple"?

Respuesta: ninguno.

¿Será tan necesario o conveniente usar la "herencia múltiple"?

Me da la impresión que estás opinando sin haber leido. Escribir un compilador o un kernel no hace a un programador POO, es más, dudo que usen OO.

Finalmente, la última frase que escribes me parece grueso disparate (a menos que fuera un mensaje subliminal).

> El primer argumento que has usado es el que más odio xD: "Como es complicado, no lo > soporta el lenguaje". Si es complicado, o no te atreves con ello, no lo uses.

Mmmm ... te está fallando el módulo de la compresión lectora. Nunca dije que fuera complicado. Si quieres un paralelismo: similar caso con el "goto" en muchos lenguajes. Hay lenguajes que lo implementan, otros que lo eliminaron, etc, pero finalmente todos los argumentos apuntan a desaconsejar su uso (esté disponible o no) por un problema de "diseño".

> Como Java soporte algún día la herencia múltiple, voy a reirme mucho xD Yo no suelo > usar herencia múltiple, pero QUIERO que esté abierta la posibilidad.

Puede ser que algún día la soporten, pero como ya argumenté, la propia gente de Java no incluye esta posibilidad porque se adhieren al mismo principio: "evitar el uso del goto moderno".

> La excusa de "no está porque es un desastre" no es válida. Si existe la herencia
> múltiple es porque hubo gente que la vió útil.

Me imagino que aquí querrás decir "no me es válida". No conozco la historia de su creación, pero perfectamente se pudo haber creado y luego haber desaconsejado (ídem famoso caso "goto").

Existe un patron llamado "Interfaz de Negocio" el cual es susceptible de usar herencia multiple.

Con respecto a que se duplican los atributos: en C++ este problema es solcionado con la palabra clave "virtual".

Mmmm ... pero no es del GOF, no? ;-) (si podés, mandame una url para leerlo).

Como patrones de diseño, existen muchos, de muchos autores. El mismo GOF es una recopilación de patrones que no necesariamente crearon los autores del libro.

Hasta yo puedo crear un patrón y usar la herencia múltiple, pero eso no quiere decir que sea la mejor solución a un problema, ni que este pueda aplicarse en otros contextos.

Lo que quiero decir con los patrones, tomando como referencia un libro base reconocido mundialmente, es que ninguno de los patrones (de los 23) hacen uso de la herencia múltiple, y tampoco la sugieren.

Los patrones de diseño son considerados la mejor "receta de cocina" para resolver un problema recurrente, con el mejor diseño posible, donde puede ser aplicado en otros contextos (concepto de patrón: "elemento reutilizable de experiencia y conocimiento").

Otro detalle: generalmente cumplen todos el principio de "Abierto/Cerrado" (Open/Close), que dice "nuestros diseños deberían ser cerrados al cambio pero abiertos a la extensión", lo que hace que esté controlado el "foco de cambio" (donde generalmente se aplican los patrones).

No he visto en ningún texto que documente principios, sugerencias, guías o buenas prácticas de diseño que recomienden el uso de la herencia múltiple. Es más, lo que he visto es todo lo contrario, hacen mucho hincapié en controlar el uso de la herencia simple, llegando a desaconsejar hasta la sobreescritura de los métodos (por el hecho de "¿para que heredas si luego sobreescribes el comportamiento?").

Tampoco he leido que exista una discusión importante sobre el tema ni que hubiera una campaña para su uso. Creo que no se discute mucho el hecho de la "no conveniencia" del uso de la herencia múltiple.

Creo que el tema va más allá del lenguaje, el problema no es si un lenguaje lo soporta o no (volviendo al ejemplo del "goto"), el problema es si se debe usar o no, y los efectos que pueden causar sobre nuestro diseño y su mantenimiento.

No hace falta dar ninguna referencia: A los que se les ocurrió el concepto de herencia múltiple, a los que lo implementaron en ciertos lenguajes, a los que lo estandarizaron (como el comité de C++, este comité representa a muchas empresas importantes como Microsoft, Apple, IBM y Sun) y personas que lo usan, creo que es evidente que están de acuerdo con ello.

Pues mi impresión es que no has entendido lo que he escrito. ¿Cuándo he dicho yo que en un compilador o kernel se use la programación POO?

Trato de explicar que no sólo los que escriben libros son los que saben.

Es como los músicos, sólo los ricos y famosos dan su opinión.

Y dale con el diseño. El diseño corre a cargo del programador, no del lenguaje. Si quieres usar inadecuadamente las características del lenguaje, éste no debe prohibírtelo.

El "goto" es necesario. Es más, en ciertos lenguajes, de pasar a ser "goto" a pasado a ser mejorado.

Por ejemplo, C++ mejoró el "goto" de siempre permitiendo definir variables que hacían referencia a etiquetas estáticas. Mientras antes usabas el "goto" a una etiqueta, ahora le puedes hacer a una variable que contenga a la etiqueta.

Así que fíjate cómo ha decaído ;) Al revés, es un concepto interesante el poder hacer saltos así de manera portable entre plataformas.



Querrás decir que los de Sun tratan de abolir ciertas técnicas de programación que han estimado malas. El "goto" no es posible eliminarle en C/C++ por ejemplo, simplemente es necesario disponer de una alternativa portable para realizar saltos incondicionales.



No, quiero decir lo que he escrito. Un argumento que critica algo calificándolo de "malo" es subjetivo, y por tanto no es un argumento. Será malo para ti, para otro quizás no.



El "goto" existe (y seguramente existirá) porque es el equivalente a la instrucción "jmp" de ensamblador, se debe dejar al programador la libertad de usarla, y en algunos casos concretos es útil.

Nadie inventó el goto, existía desde que nacieron los procesadores. Y luego no se desaconsejó, sino que se instó a los programadores novatos que aprendiesen a no sobreexagerar su uso y que aprendieses las maneras correctas de hacer las cosas, como se sigue haciendo.

La herencia múltiple, es otra cosa. Es no equivale a un "jmp", sino a muchas más cosas, y hubo que diseñarlo tranquilamente. A mi parecer, si sigue existiendo en ciertos lenguajes que han evolucionado, es porque a mucha gente le ha interesado o ha dado razones para que esté ahí.


PD: No desviemos el tema al "goto".

Centrándonos en el tema:

¡! Lo que te digo, no uses la POO y te ahorras complicaciones.

Y te respondo a la pregunta: Heredas y reescribes para luego que los objetos sepan administrarse de manera autónoma cuando les llamas para realizar una función.

El ejemplo típico, un videojuego/simuladores con todas las clases de objetos que tienen, y que tienen que actualizar en tiempo real. Llaman a todos por la misma función y ellos sólos hacen lo que deban hacer según qué sean.

Si no, ¿cómo controlas qué debe hacer cada objeto? ¡Ah, sí! Lo que se llama "downcasting", que en C++ se usa junto a la RTTI usando castings dinámicos: dynamic_cast<Hijo>(Padre);

Pero eso sí es lento y genera cascadas de condicionales que ralentizan la ejecución. Aún así, es muy útil, y no por que sea un "fregao" sugiero que lo eliminen de C++.


Pues sí, se discute. Fíjate, ahora mismo lo estamos haciendo.

Esto es una opinión, pero veo que muchos pro-Java creen que lo que representa "Java" es el estándar en programación, y dan por supuesto que si por ejemplo Java no tiene herencia múltiple, es que no se discute sobre ello.


Repito: El problema lo causa el programador, no el lenguaje.

Por la misma regla de tres, no uses ni herencia simple siquiera, ni clases, ni nada. Simplemente usa un lenguaje estilo Basic, como C sin punteros, y ya está. Todo simplificación. No tendrás ningún problema.

Al menos yo no quiero ser un pardillo al que me quiten posibilidades.

Sólo puedes saberlo si compruebas opensources.

Pero hay sistemas operativos (incluido kernels) que usan POO y compiladores, eso tenlo por seguro, al igual que hay otros que sólo usan ensamblador de principio a fin (MenuetOS), desde el kernel hasta la GUI pasando por las aplicaciones ofimáticas y el navegador de internet.

Así como en los videojuegos es prácticamente imprescindible usar la POO, y la PG también.


¿Cuál de todas? Porque no hiciste quote.

> No hace falta dar ninguna referencia: A los que se les ocurrió el concepto

Hasta los malos libros deben hacer referencias a sus fuentes ;-)

> herencia múltiple, a los que lo implementaron en ciertos lenguajes, a los que lo
> estandarizaron (como el comité de C++, este comité representa a muchas
> empresas importantes como Microsoft, Apple, IBM y Sun) y personas que lo
> usan, creo que es evidente que están de acuerdo con ello.

Veo que te quedaste en el C++ y no saliste a conocer el mundo ;-)

> Pues mi impresión es que no has entendido lo que he escrito. ¿Cuándo he
> dicho yo que en un compilador o kernel se use la programación POO?

Estamos en el foro de "PHP Orientado a Objetos" y el tema que estamos hablando es "herencia múltiple en PHP5", lo cual derivó en una discusión sobre diseño orientado a objetos.

¿Tu de qué estás hablando? ;-)

> Trato de explicar que no sólo los que escriben libros son los que saben.
> Es como los músicos, sólo los ricos y famosos dan su opinión.

Mmmm ... buena filosofía personal. Por lo visto debe generar rechazo a los libros, algo que he evidenciado en otros comentarios y te lo hice saber.

No veo que podamos seguir intercambiando opiniones si venimos de fuentes tan distintas de información.

> ¡! Lo que te digo, no uses la POO y te ahorras complicaciones.

Bueno, se disparó tu puntero al infinito y más allá ;-)

> Pues sí, se discute. Fíjate, ahora mismo lo estamos haciendo.

Disculpa, estás hablando desde dentro de una "caja", hay todo un mundo allá afuera.

> Esto es una opinión, pero veo que muchos pro-Java creen que lo que
> representa "Java" es el estándar en programación, y dan por supuesto que > si por ejemplo Java no tiene herencia múltiple, es que no se discute sobre ello.

Considero que en la actualidad Java es más representativo como estándar de la programación que C++.

Y sobre herencia múltiple, sí, no se discute sobre ello, se están discutiendo de cosas más trascendentes que esto.

> Repito: El problema lo causa el programador, no el lenguaje.

Por eso se desaconseja el uso del "goto", y por la misma razón, se considera innecesario implementar la "herencia múltiple" en muchos lenguajes modernos.

Estamos hablando de lo mismo.

> Por la misma regla de tres, no uses ni herencia simple siquiera, ni clases, ni > nada. Simplemente usa un lenguaje estilo Basic, como C sin punteros, y ya > está. Todo simplificación. No tendrás ningún problema.

Los extremos y las generalizaciones son malas.

> Al menos yo no quiero ser un pardillo al que me quiten posibilidades.

Bien por ti.

> El "goto" es necesario. Es más, en ciertos lenguajes, de pasar a ser "goto" a > pasado a ser mejorado.

¿Cuales lenguajes siguen implementando el "goto" y además, aconsejan su uso (descartando C++, obviamente)?

> Por ejemplo, C++ mejoró el "goto" de siempre permitiendo definir variables
> que hacían referencia a etiquetas estáticas. Mientras antes usabas el
> "goto" a una etiqueta, ahora le puedes hacer a una variable que contenga a > la etiqueta.

Pensé que los dinosaurios se habían extinto, pero veo que estoy hablando con el último carnivoro (yo me considero también uno, pero me he vuelto vegetariano ;-) )

> Así que fíjate cómo ha decaído ;) Al revés, es un concepto interesante el
> poder hacer saltos así de manera portable entre plataformas.

Me parece que ver la realidad a través del cristal de C++ no te hace muy objetivo.

> Querrás decir que los de Sun tratan de abolir ciertas técnicas de
> programación que han estimado malas.

Interpreto que es así, y no es exclusividad de Sun.

> PD: No desviemos el tema al "goto".

Lo cortés no quita lo valiente. Fue un ejemplo para tratar de explicarlo más claro.

No uso el "goto" para saltar el tema.

> Sólo puedes saberlo si compruebas opensources.

¿Si "compruebo opensources"? Tu dices si uso software Open Source?

Si, vivo de él, me dedico a la consultoría basada en Software Libre / Open Source.

> Pero hay sistemas operativos (incluido kernels) que usan POO y
> compiladores, eso tenlo por seguro, al igual que hay otros que sólo usan
> ensamblador de principio a fin (MenuetOS), desde el kernel hasta la GUI
> pasando por las aplicaciones ofimáticas y el navegador de internet.

No digo que no se use (la OO en la actualidad es un paradigma muy extendido), pero es poco habitual. Muchos sistemas operativos, Unix-Like, usan C y ni siquiera C++.

¿Cuales conoces que sean OO?

> Así como en los videojuegos es prácticamente imprescindible usar la POO,
> y la PG también.

¿La "PG"?

> ¿Cuál de todas? Porque no hiciste quote.

Como dije originalmente, la última. ;-)

¿Estás insinuando que yo soy un "mal libro"? Bueno, no veo qué he dicho que sea mentira.

No, me quedé en C++ porque es lo que requiere mi campo de la programación. No puedo usar PHP o Java para ciertas cosas que quiero hacer, así como no me gusta depender de nada. Además, he leído muchas discusiones y comparaciones entre lenguajes, pero no es la cuestión. Aquí tratamos de la herencia múltiple (poniendo ejemplos claro).

Repito: ¿Cuándo he dicho yo que un compilador/kernel use OO? Lo has puesto en mi boca y no has respondido, lo tomaré como que te equivocaste, no pasa nada. Hablo de herencia múltiple.

No rechazo los libros, eso son conclusiones que tú sacas. Lo que no hago es rechazar las opiniones personales, de la gente que lo usa en la práctica, como haces tú. De hecho, leo libros, normalmente los que me parecen mejores, y tienen en cuanta la práctica.

Ejemplo: Los de Scott Meyers son geniales.

Como veo, no has entendido mi comentario. C++ no aconseja ni desaconseja el uso de ninguna técnica., simplemente deja a decisión del programador lo que debe de hacer.

No lo hace, porque C++ es un lenguaje, no es algo que tenga opinión por sí misma. Parece que hablas de Java, en vez de lenguaje, como una secta, donde se decide todo a rajatabla.

Los que opinana son las personas, no los lenguajes, y en C++ hay mucho debate entre programadores sobre qué usar y qué no. Pero lo hay, porque hay libertad, y porque cada uno decide que usar o no usar.

Yo puedo decir que no apoyo la herencia múltiple pero uso C++. ¿Hay algún problema? Que use C++ no quiere decir que use todo lo que permite.

Si tú me crees un carnívoro por usar C++, deberías dejar tu "mundo real", y pasarte a ver mi mundo, quizás te sorprendas de cuántos carnívoros hay para hacer tu máquina virtual Java, tu intérprete de PHP y los sistemas sobre los que se apoya. Típico, ¿eres de los que usan los lenguajes por lo que aparentan? Cosas como "Estudio J2EE porque es la moda", dicen muchos.

Pero si quieres más información:
El "goto", lo implementan: Fortran (de los primeros), Algol, Cobol, Snobol, Basic (GW-Basic, Visual Basic, QuickBasic, QBasic...), Lisp, C, C++, C++0x, C++/CLI, D (y este es un lenguaje de alto nivel, y NUEVO), Pascal, Perl (y supongo que sus similares como Python). [Sacado de la wikipedia].

Al menos, no son como Java, que tiene una palabra reservada para el "goto", pero no sirve para nada literalmente (según leo en la Wikipedia en inglés). Es decir, está puesto como "por hacer", o "a decidir". Programar en un lenguaje que está a medias... Malo. :P

> Como veo, no has entendido mi comentario. C++ no aconseja ni
> desaconseja el uso de ninguna técnica., simplemente deja a decisión del
> programador lo que debe de hacer.

Bueno, nos vamos acercando a un "diálogo de sordos" ... yo no dije que C++ aconsejara directamente (?!) ... pregunté que lenguajes usaban "goto", descartando C++, y luego, quién, que autor, libro, aconseja esta práctica.

Tal vez quedaron mezcladas las palabras, pero creo que se entiende la idea de la pregunta.

> No lo hace, porque C++ es un lenguaje, no es algo que tenga opinión por sí > misma. Parece que hablas de Java, en vez de lenguaje, como una secta,
> donde se decide todo a rajatabla.

Eres demasiado prejuicioso y veo que rechazas todo lo que no sea C++ ... he trabajado académicamente en Java y en .Net, pero no los prefiero a la hora de desarrollar, pues me especializo en software open source. Pero me da una visión más amplia de la realidad conocer otros entornos y luego poder aplicar los conocimientos y experiencia en mi entorno particular.

Y no, a pesar que prefiero PHP5 (por ejemplo), no soy fanático extremista religioso de ninguno (he probado Ruby On Rails, por ejemplo).

> Si tú me crees un carnívoro por usar C++, deberías dejar tu "mundo real", y > pasarte a ver mi mundo, quizás te sorprendas de cuántos carnívoros hay
> para hacer tu máquina virtual Java, tu intérprete de PHP y los sistemas

Son desarrollos particulares que necesitan herramientas particulares. El grueso del mercado está buscando lisa y llanamente "productividad". C++ no es un lenguajes productivo para los negocios, tal vez Java tampoco sea el ideal para la mayoría de los casos, ... por eso se está tratando de investigar en otras direcciones (estamos en la "Era de los Frameworks", por ejemplo).

> sobre los que se apoya. Típico, ¿eres de los que usan los lenguajes por lo
> que aparentan? Cosas como "Estudio J2EE porque es la moda", dicen muchos.

Sos un veterano prejuicioso ... y además, debes fumar como una chimenea ;-)

He leído sobre J2EE pero nunca trabajé en la vida real. Trato de tomar estos conocimientos y aplicarlos en ambientes como PHP5.

> Pero si quieres más información:
> El "goto", lo implementan: Fortran (de los primeros), Algol, Cobol, Snobol,
> Basic (GW-Basic, Visual Basic, QuickBasic, QBasic...), Lisp, C, C++, C++0x, > C++/CLI, D (y este es un lenguaje de alto nivel, y NUEVO), Pascal, Perl (y
> supongo que sus similares como Python). [Sacado de la wikipedia].

Confirmado, la mayoría son lenguajes de la "Era del Hielo".

> ¿Estás insinuando que yo soy un "mal libro"? Bueno, no veo qué he dicho
> que sea mentira.

Cuando dices que "No hace falta dar ninguna referencia" cuando te pregunto donde te apoyas para afirmar lo que dices y solo te quedas con que es válido por solo el hecho de haber sido creado y existir.

> No, me quedé en C++ porque es lo que requiere mi campo de la
> programación. No puedo usar PHP o Java para ciertas cosas que quiero

Si, era demasiado evidente ;-)

> Repito: ¿Cuándo he dicho yo que un compilador/kernel use OO? Lo has
> puesto en mi boca y no has respondido, lo tomaré como que te
> equivocaste, no pasa nada. Hablo de herencia múltiple.

Tu sacaste este tema en el contexto equivocado. Si en este contexto hablas de programar un compilador o un kernel, debo asumir que estás haciendo referencias a OO.

Gracias, pero cuando me equivoque seré el primero en decirlo.

> como haces tú. De hecho, leo libros, normalmente los que me parecen
> mejores, y tienen en cuanta la práctica.
> Ejemplo: Los de Scott Meyers son geniales.

Lástima que estén basados solo en C++.

Tal vez sería bueno leer libros más genéricos, de alto nivel (diseño OO, patrones, etc), o de otras tecnologías (J2EE, .Net, etc), para ampliar la visión, o como cultura general.

No sacar cada vez que puedes la palabra "C plus plus" ;-)

(No hago quotes porque son respuestas sencillas)

La productividad de C++ depende mucho del ámbito. Por ejemplo, la mayoría de empresas con tiempo a sus espaldas, tienen ya desarrollados sus propias librerías, "frameworks" y demás, y llegaron a ser muy productivas. Ahora bien, para aplicaciones de gestión y demás, sí, lenguajes como C# son más aptos. Pero para cosas como videojuegos, aprender de arquitectura de ordenadores o redes, o sistemas operativos, pues no.

Fumo fumo :)

También pretendo programar para ciertos proyectos de software libre (no sólo open source) y C/C++ es lo mejor para ese ámbito, sin duda, sobre todo para contribuir con temas avanzados en GNU/Linux.




A esto sí hago quote... Bueno, no sé a qué llamas tú "Era del hielo", pero:

* C++ se ratificó el último estándar en 2003.

* D es un lenguaje nuevo, que está intentando encontrar hueco, pero las empresas no gustan de volver a apoyar un lenguaje libre (como C++). En realidad, tiene la potencia de C++, la simplificación de C#, más pureza estilo Java... Deberías consultar su web. Verás que es el lenguaje "ideal".

* C++/CLI es el lenguaje que está desarrollando Microsoft ahora mismo y que acaba de salir su última versión. Permite usar al mismo tiempo código C++ normal, con sus clases y librerías normales, y el framework, sus tipos manejados, su sistema de clases, etc.

* Y para terminar, C++0x es el último estándar de C++ que saldrá en el 2010. Es decir, hablamos del futuro.

En cualquier caso, Perl, Python, Lisp, Pascal (o Object Pascal con Delphi) y demás, se siguen usando a nivel diario para la administración de ordenadores, sobre todo en *NIX.

Te estarás refieriendo a la siguiente Era de Hielo ;)

recuerden que esté fué el post que abrió este hilo:

Con todo respeto y sin animo de ofender, no les parece que se fue un poco de mambo ya?
Tal vez pueda interesarle este tema a otras personas, pero abran un post nuevo y sigan discutiendolo y dejen lugar para que quienes quieran discutir del tema original puedan hacerlo.
nuevamente, no se lo tomen a mal, pero creo que no es sano para el foro este tipo de post. (interesante, pero fuera de lugar)

saludos

No a ver, lo que digo es que la herencia múltiple salió porque era evidente, "¿qué hacemos si pudiésemos tener varios padres?". Se planteó, se vio que era algo bueno (como dice el génesis :P), y se implementó.

Y se sigue implementando en los consiguientes estándares de C++ (y digo C++ porque es el único lenguaje del que conozco los últimos estándares, y se que lo incluyen).

Cuidado, que programe en C++ (en realidad estoy aprendiéndolo y no creo que pueda acabar nunca de complejo que es :P), no quiere decir que no conozca otros lenguajes. He usado ensamblador, VB6, Perl, C# (bastante), VB.Net, empecé con Java (pero entonces leí las críticas, vi el rollo que suponía y decidí que me iba a ser una pérdida de tiempo, porque no lo iba a poder usar en otros lugares), y otros que no vienen a cuento.

El resultado es que tuve razón: Siguieron sacando nuevos Java y decidí que si alguna vez necesitaba algo, lo aprendería (no me cuesta nada aprenderme las bases de un lenguaje, y Java es clavado a C++). Por otra parte, en C++ no conozco aún ni la mitad, ya te puedo decir yo que en C++, si no trabajas con el al menos 5 años no lo vas a conocer en realidad. Muchos licenciados españoles que conozco salen diciendo "he aprendido Pascal, Eiffel, Smalltalk, C, C++, Java...". Luego les preguntas que qué es una template, y no lo saben. Resultado: Ni idea de C++. Y lo mismo con Java o C ;)

Pues no, está a punto de sacar (si es que no lo ha hecho ya que no lo sé, lo mire hace meses) una colección sobre C#, VB.Net y otros dos si no recuerdo mal.

En cualquier caso, los apuntes que da de C++, sirven para la mayoría de lenguajes POO y que usen algo similar a las templates, es un compendio de las ramas de la programación avanzada (no sólo exclusiva de C++) muy interesante.

He leído bastante (no sólo libros), sobre programación en general, patrones, estructuras de datos, sistemas operativos (cómo arrancan, cómo funcionan, drivers, manejo de memoria, ...), patrones de diseño... etc. Pero vamos, todo ayuda aunque sea indirectamente como bien dices.

No pienso leer libros sobre J2EE o .Net, porque aún no he terminado con C++. Lo intenté, pero vi que si mezclaba C# y C++ y Java, se me hacía un cacao mental de reglas de los distintos lenguajes y terminaría consumiendo más tiempo así que aprendiendo por separado, o eso, o con ideas equivocadas. Difieren en aspectos muy sutiles y que a veces hay que conocer. Pero vamos, podría hablar de C# un buen rato. Le uso normalmente para tareas que no requieran complicación o que no vaya a mantener.

Sobre lo de videojuegos/compiladores/kernels/..., estaba hablando de que programadores avanzados (es evidente que ellos lo son y por eso puse ejemplos así) tienen opinión también, que son los que al final dan el callo y programan; y los que publican libros, quizás no tengan tanta (o quizás tengan más).

Lo que pretendía decir es que la verdad no está toda en los libros. Es más, normalmente tiende más a mentira que a verdad, sobre todo en los de historia :P