Nueva Encuesta de Embarcadero

[Al González]

Hoy me apareció en Twitter un mensaje de Paolo Rossi (https://twitter.com/awebguy), quien acaba de hacer lo que, en mi opinión, deberíamos hacer todos los presentes:

Participar en la nueva encuesta de Embarcadero sobre RAD Studio, Delphi y C++Builder (https://www.surveymonkey.com/s/2014RADStudioSurvey). Recuerden que las encuestas son una muy buena forma de influir en las decisiones de quien las convoca, a fin de obtener resultados que favorezcan a la mayoría de los participantes (al menos en teoría). Así que los exhorto a que participen.

¡Venga ese ánimo! :)

https://www.surveymonkey.com/s/2014RADStudioSurvey

Saludos cordiales.

[Casimiro Notevi]

^\||/^\||/^\||/

[Al González]

^\||/^\||/^\||/
Creo que las preguntas sobre Linux y la pregunta abierta de qué característica te gustaría que se agregara van a resultarte de las más interesantes, Casimiro. :) ^\||/

[Casimiro Notevi]

2. Which language would you use the IDE in if RAD Studio were also available in additional languages than those above?
https://www.surveymonkey.com/i/t.gifWhich language would you use the IDE in if RAD Studio were also available in additional languages than those above? None, the languages supplied are sufficient
https://www.surveymonkey.com/i/t.gifChinese
https://www.surveymonkey.com/i/t.gifRussian
https://www.surveymonkey.com/i/t.gifPortuguese
https://www.surveymonkey.com/i/t.gifSpanish
https://www.surveymonkey.com/i/t.gifKorean
https://www.surveymonkey.com/i/t.gifItalian
https://www.surveymonkey.com/i/t.gifDutch
Other (please specify)

[lbidi]

Estimados , les dejo un link de la ultima encuesta de Embarcadero con 103 preguntas muy interesantes algunas y sobre todo, a mi entender, varias preguntas sobre que esperamos o necesitamos de nuestro tan querido Delphi.

https://www.surveymonkey.com/s/2014RADStudioSurvey

Saludos.

[Al González]

Hola. :)

Dado que se trata del mismo tema, sugiero que sean unidos ambos hilos.

http://www.clubdelphi.com/foros/showthread.php?t=86173

Un cordial saludo.

[lbidi]

Tienes razon Al, no habia visto el post anterior.

Lamento haber posteado la misma noticia.

Saludos.

[Casimiro Notevi]

He unido ambos hilos, perfecto :)

[Al González]

Tienes razon Al, no habia visto el post anterior.

Lamento haber posteado la misma noticia.
No pasa nada. :)

Lo importante es que todos seamos partícipes del destino de Delphi, incluso en las tediosas encuestas. :p

Por lo pronto ya propuse que el compilador de Delphi permita redefinición de clases (herencia insertada), aunque de antemano sé que a casi nadie le interesan mis locas ideas. :rolleyes:

[nlsgarcia]

Al González,


...que el compilador de Delphi permita redefinición de clases (herencia insertada)...

Pregunto:

1- ¿Que es Herencia Insertada? :confused:

2- ¿No sería mejor Herencia Múltiple en Delphi? :rolleyes:

Saludos,

Nelson.

[Al González]

1- ¿Que es Herencia Insertada? :confused:
Hola Nelson. :)

Aunque es algo teórico en Delphi todavía, básicamente consiste en que, teniendo una jerarquía de clases tal como:

...
|
TA
|
---------
| |
TB TC
| |
----- -----
| | | |
... ... ... ...

puedas derivar e "insertar" una clase TA1 (o "redefinir" la clase TA), agregándole más campos, métodos y todo lo que puede tener una clase normal (cosa que no satisfacen los ayudantes de clases). De tal manera que la nueva clase quedaría en el esquema así:

...
|
TA
|
TA1 (clase "insertada")
|
---------
| |
TB TC
| |
----- -----
| | | |
... ... ... ...


Y todo, claro, sin necesidad de modificar el código fuente de las clases ya existentes.

Aunque no lo he revisado, recuerdo que Román comentaba hace tiempo que esta característica se encuentra presente en JavaScript.

Un saludo.

[nlsgarcia]

Al González,


...Aunque es algo teórico en Delphi...básicamente consiste en que, teniendo una jerarquía de clases...puedas derivar e "insertar" una clase...sin necesidad de modificar el código fuente de las clases ya existentes...
Gracias por la información :rolleyes:

Pregunto : ¿Y el uso de Herencia Múltiple en Delphi no sería también una opción a considerar? :confused:

Saludos,

Nelson.

[Al González]

¿Y el uso de Herencia Múltiple en Delphi no sería también una opción a considerar?
Creo que la herencia múltiple debe ser considerada también, aunque tratando de la mejor forma posible el problema del diamante (http://es.wikipedia.org/wiki/Problema_del_diamante).

Saludos.

[nlsgarcia]

Al González,


...Creo que la herencia múltiple debe ser considerada también, aunque tratando de la mejor forma posible el problema del diamante...

:rolleyes:


...Hay debate sobre si la herencia múltiple puede ser implementada de forma simple y sin ambigüedad. Con frecuencia es criticada por su aumentada complejidad y su ambigüedad, así como los problemas de versiones y mantenimiento que puede causar (a menudo resumido como el problema del diamante)...

Tomado de: Herencia múltiple (http://es.wikipedia.org/wiki/Herencia_multiple)

Supongo que por estos problemas de ambigüedad, Delphi y C# utilizan interfaces como una forma alternativa de herencia múltiple.

Saludos,

Nelson.

[mamcx]

Creo que la herencia múltiple debe ser considerada también, aunque tratando de la mejor forma posible el problema del diamante (http://es.wikipedia.org/wiki/Problema_del_diamante).

Saludos.

Hacer herencia multiple es multiplicar el problema de la herencia. Es por eso que es mejor:

Composicion sobre herencia (https://en.wikipedia.org/wiki/Composition_over_inheritance).

Luego de muchos años de hacer OO, es claro que la herencia es la forma *errada* de lograr la reutilizacion de codigo:

http://raganwald.com/2014/03/31/class-hierarchies-dont-do-that.html

http://javarevisited.blogspot.sg/2013/06/why-favor-composition-over-inheritance-java-oops-design.html

No solo porque arrastran todo el edificio cuando solo necesito prestado un martillo, sino porque hacen rigido el esquema del código y complican jodidamente el poder reusar el codigo.

Hay 2 formas que serian mucho mejor, pero seria complicado retro-corregir un lenguaje como Delphi/Java.

El metodo mas practico (desde el punto de vista del acostumbrado a OO) y parecido es el de GO:

http://www.onebigfluke.com/2014/04/gos-power-is-in-emergent-behavior.html

El segundo son los multi-metodos:

http://nice.sourceforge.net/visitor.html (Implementado en NICE, un lenguaje parecido a Java)

Y en Julia, que es mas funcional:

http://julia.readthedocs.org/en/latest/manual/methods/

----

El asunto del porque la herencia es la solucion herrada (no siempre, pero muchas veces) es que es una violacion de la idea de

http://users.ece.utexas.edu/~adnan/pike.html

Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.


Y

Plano es mejor que anidado
---Zen de Python

Un ejemplo de se muestra en http://www.onebigfluke.com/2014/04/gos-power-is-in-emergent-behavior.html es el de hacer una app que sirva como un servidor web.

Como se soluciona tipicamente? Pues tienes que tener un IndyHTTP o un SinapseHTTP, heredar de eso, y implementar el metodo(s) que REALMENTE es necesario, pero ademas, probablemente reimplementar un monton de otros. Y como se arrastra TODA la jerarquia, no siempre es claro que hay que reimplementar (no saben cuantas veces se ignora reimplementar metodos como el de hash, igualdad y otros).

En cambio, tomando a GO por ejemplo, si quieres que tu codigo sea un servidor web (ilustrando con un ejemplo bastardizado de pascal):


procedure Clientes.ServeHTTP(w as http.ResponseWriter; var r as http.Request)
begin
r.write("El cliente esta feliz!");
end;

Este codigo: Declara que conforma con la interface de un servidor web, define su implementacion y se encarga de pasar los param de request/response. Noten que esta totalmente desacoplado, es testeable, no hay que "montarlo" sobre puertos, Es irrelevante el porque rayos mi clase de manejos de clientes de un momento a otro puede ser un servidor web, es totalmente compatible con cualquier codigo que acepte esa interface. Un monton de cosas, y a la vez: No hay herencia, no se traen tropocientos metodos inutiles, no trae codigo inutil, no importa si la implementacion de sockets es Synapse o Indy o lo que sea, no importa que Clientes no es una libreria exclusiva de servidores web...

No hay que crear una subclase. No hay que reimplementar nada. No hay que pensar cual de los tropocientos metodos y campos son o no importante. No se puede, por error o brutalidad, llamar a un metodo o campo del padre que no tiene importancia, es inutil o hace un desastre.

Y se puede hacer herencia, algunas veces...

P.D: Una forma de lograr lo que se quiere de la herencia multiple, sin traer sus problemas y promover el desacoople es permite re-abrir funcionalidad de una clase, una forma de como se ve esto:

https://developer.apple.com/library/prerelease/mac/documentation/Swift/Conceptual/Swift_Programming_Language/Extensions.html

Pascal bastardizado:



reopen TControl
constructor (center as TPoint, size as TSize):
begin
end;

function print():String
begin
end;


El cambio es localizado, no hay herencia (plus), se pude jalar lo necesario de otras clases(s)/funciones (incluso de varias) y no se "contamina" toda la clase de forma universal.

[Al González]

Supongo que por estos problemas de ambigüedad, Delphi y C# utilizan interfaces como una forma alternativa de herencia múltiple.
Sí, y es que el uso de interfaces es limpio y suficiente para muchos casos.

Pero me extraña ver tantas disertaciones sobre herencia múltiple con todos los contras que tiene, y casi ninguna mención a la redefinición de clases (o "herencia insertada"), en lenguajes populares como Delphi, C#, etc.

Por otra parte, mamcx, he notado que haces mucho hincapié en las dificultades para reutilizar código cuando éste se encuentra en métodos de clases y sólo necesitamos uno de esos métodos o parte de él, y no toda la jerarquía de clases que arrastra. Me pregunto si habrás mirado con detenimiento en GH Freebrary (http://www.clubdelphi.com/foros/showthread.php?t=84953), donde hay más de 40 clases y la mayor parte del código fuente que éstas emplean se encuentra separado en cientos de funciones independientes. Así el programador tiene la libertad de usar una clase de esta biblioteca o solamente las funciones que necesita, según sea su objetivo. Y es que yo me tomo muy en serio lo del aprovechamiento y reutilización del código, sin caer en aquella tristemente exitosa trampa conceptual de que "encapsular" es meter todo el código fuente en los métodos.

Un saludo.

[mamcx]

No conozco GH Freebrary, llevo un rato desconectado de trabajo serio en Delphi (:(). Por lo que describes, estas empleando el concepto de "Composicion sobre herencia", que fue desarrollado precisamente entre los lenguajes OO, tal como explica el link de wikipedia. Me parece que eventualmente todo programador experimentado en OO llega, aun sin darse cuenta y de forma informal, a la idea puramente porque es una forma mas sana de trabajar.