nesecito enviar mensajes a objetos de un DataModule.Components[i]

[orfeo]

hola, Uso Delphi 6 y quiero enviar mensajes a que todos los Tquery de un DataModule, mi codigo es:


for i:=0 to (DataModule1.ComponentCount-1) do
if (DataModule1.Components[i] is Tquery)
then begin
ClassRef :=DataModule1.Components[i].ClassType;
Tquery(ClassRef).close;
end;

esto falla en el close, probe de varias maneras, pero sin muchos
resultados, salta errores de direcciones de memoria.

como podran ver mi POO de Delphi es 0

[roman]

Posteado originalmente por orfeo
for i:=0 to (DataModule1.ComponentCount-1) do
if (DataModule1.Components[i] is Tquery)
then begin
ClassRef :=DataModule1.Components[i].ClassType;
Tquery(ClassRef).close;
end;


No entiendo por qué el uso de ClassType. Me parece que bastaría poner:


TQuery(DataModule1.Components[i]).Close;


// Saludos

[orfeo]

la verdad que no recuerdo aberlo probado :)
ahora que lo leo parece sencillo, sin tanto codigo...

y por lo de ClassType lo saque del help, talves era para otra cosa :)

[delphi.com.ar]

Bueno, ante todo aclaremos que estas confundiendo los temas, no estas enviando mensajes, estas queriendo ejecutar un método propio de una clase, tené en cuenta que los mensajes solo se los puedes enviar a las ventanas, en Delphi todos los componentes heredados de TControl y alguno otro en particular que cree una ventana.
Supongo que lo que querés hacer es algo como esto:


for i:=0 to (DataModule1.ComponentCount-1) do
if (DataModule1.Components[i] is TQuery) then
TQuery(DataModule1.Components[i]).close;

[roman]

Posteado originalmente por delphi.com.ar
Bueno, ante todo aclaremos que estas confundiendo los temas, no estas enviando mensajes, estas queriendo ejecutar un método propio de una clase...


No exactamente. Desde el punto de vista de programación orientada a objetos, los objetos se mandan mensajes unos a otros y la manera de hacerlo, en lenguajes como Delphi, es llamando métodos de un objeto. Cuando ejecutamos


Rectangulo.Dibujar


estamos enviando el mensaje "Dibujar" al objeto "Rectangulo"

Al mandar un mensaje a una ventana, a final de cuentas también estamos ejecutando un método, WndProc, aunque indirectamente.

El punto es que aunque haya diferencias entre cómo mandar los mensajes la idea esencial es la misma: mandar un mensaje a un objeto para que realice una acción.

// Saludos

[delphi.com.ar]

Discrepo totalmente, me parece que tu punto de vista solo va a complicar la comprensión del tema de un principiante, los mensajes son mensajes y los métodos son métodos sin inportar lo que hacen internamente, sinó tenemos que tirar por la borda toda la teoría de encapsulamiento.

[__marcsc]

Hola,

es cierto que existen los dos significados...

- Desde el punto de vista cuotidiano del programador windows, entendemos que enviar un mensaje es ejecutar una llamada a la API de Windows.

- Sin embargo, cuando se estudia la orientación a objetos desde el punto de vista teórico, lo que nos venden ( o al menos me vendieron a mi) es que los métodos son la manera de implementar lo que a nivel conceptual es enviar un mensaje a un objeto.

Quizás fue por eso que el compañero orfeo dio esta nomenclatura a su post.

Un saludo.

[roman]

Posteado originalmente por delphi.com.ar
...los mensajes son mensajes y los métodos son métodos sin inportar lo que hacen internamente, sinó tenemos que tirar por la borda toda la teoría de encapsulamiento.

Repito lo dicho, conceptualmente los mensajes son mensajes independientemente de como se implemente su envío. ¿Y exactamente en qué se afecta la teoría del encapsulamiento?

Cuando mandas un mensaje, en la acepción que le das, con, por eemplo, SendMessage, el emisor del mensaje no sabe en qué forma la ventana receptora implemente la respuesta al mensaje (encapsulamiento) Más aún, puedes hacer "subclassing" de una ventana reimplementando su procedimiento de ventana WndProc para implementar herencia ya que desde el nuevo procediemiento puedes acceder al original. Y más aún, si, por ejemplo, cierras una ventana en Windows, el sistema manda un mensaje WMP_PAINT a todas las ventanas que estaban parcialmente ocultas y cada una responde de manera distinta al mismo mensaje. A eso le llamo polimorfismo.

La orientación a objetos es un concepto, una forma de estructurar una aplicación y no está dictada por el lenguaje que se utilice. Cierto que algunos lenguajes, como Delphi, C++, Eiffel, Java, etc. hacen más fácil el diseño orientado a objetos.

Entiendo tu preocupación por confundir a un principiante pero difiero en cuanto a sentar bases que no son correctas.

// Saludos

[delphi.com.ar]

Y exactamente en qué se afecta la teoría del encapsulamiento?
Lo que me quiero referir con el tema de encapsulamiento, es que cuando trato a una clase, no necesariamente tengo que saber qué hace internamente el método, no me importa si internamente utiliza mensajes de Windows o no, que creo que es lo que vos te querés referir.. Creo que nos estamos confundiendo en lo que discutimos, este mensaje merece ir al foro Debates... ¿no?
Estoy totalmente de acuerdo con marcsc, que desde el marco de vista te vista teórico, los métodos son la manera de implementar lo que a nivel conceptual es enviar un mensaje a un objeto, pero en Delphi creo que esta más que claro que son los métodos y que son los mensajes, pero creo que vos estas hablando de otra cosa


Saludos... y esto sigue!

[roman]

Posteado originalmente por delphi.com.ar
...Estoy totalmente de acuerdo con marcsc, que desde el marco de vista te vista teórico, los métodos son la manera de implementar lo que a nivel conceptual es enviar un mensaje a un objeto...

Esto es lo que dije desde el principio

Posteado originalmente por delphi.com.ar
, pero en Delphi creo que esta más que claro que son los métodos y que son los mensajes, pero creo que vos estas hablando de otra cosa...

Por favor relee mis respuestas. Estoy hablando exactamente de eso: de lo que conceptualmente significa el envío de mensajes en OOP y de cómo se puede implementar de distintas maneras; en Delphi con lamada a métodos, en C puro con SendMessage.

// Saludos

[__marcsc]

Hola,

solo un pequeño paréntesis :)

Si seguimos con el debate, tal vez seria mejor abrir un tema nuevo en debates y poner un enlace a este para ponernos en antecedentes, dado que este hilo lo inció orfeo con un problema que tenía.

De todos modos, y dado que el problema ya está solucionado, si entre todos os parece mejor moverlo a Debates me lo comentais y lo muevo.

Saludos!

[andres1569]

Hola:

Permitidme que tercie en al asunto para dar mi punto de vista. Estoy más con Delphi.com.ar, que argumentó en un principio que debíamos diferenciar entre mensajes y métodos.

Roman escribió :


No exactamente. Desde el punto de vista de programación orientada a objetos, los objetos se mandan mensajes unos a otros y la manera de hacerlo, en lenguajes como Delphi, es llamando métodos de un objeto. Cuando ejecutamos ...


Conceptualmente, haciendo abstracción de lenguajes y de Sistemas Operativos, como si estuviéramos escribiendo un libro de programación orientada a objetos, se puede interpretar que un método es un mensaje y viceversa (en última instancia es una acción aplicada a un objeto); pero aquí estamos programando para Windows, utilizando Delphi, y todos sabemos que no es lo mismo enviar un mensaje (SendMessage, PostMessage) que llamar directamente al método. ¿Por qué no es lo mismo? Para empezar, sí creo que afecta, aunque de una forma un tanto sutil, al encapsulamiento. Cuando llamamos a un método de un objeto, directamente ya sabemos de antemano algo del comportamiento de ese objeto. En cierta forma, nos metemos en sus asuntos. Sería algo así como llamar al método PonteElAbrigo de un objeto TPersona; la instruccion Persona.PonteElAbrigo presupone lo que debe hacer la Persona cuando hace frío y lo ejecuta sin más, no le da opción a elegir; sin embargo llamar a un mensaje deja más libertad al objeto. Si hacemos SendMessage (Persona, WM_HaceFrío), el objeto Persona puede reaccionar de diversas formas, seguramente se pondrá el abrigo, o no, y además no tendrá que hacerlo al primer aviso, podrá primero escuchar a otros mensajes (no hay que olvidar que los mensajes pueden ser asíncronos).

Siempre será más genérico enviar un mensaje que llamar directamente al método.

Quizás Roman estés pensando en un método TPersona.HaceFrio, que haga lo mismo que su mensaje homólogo, pero si os dais cuenta estamos creando un método para algo que no debería contemplar una TPersona, sino que es un acontecimiento externo(casi mejor dicho un evento).

CONCLUSION: Por norma general, los mensajes notifican eventos, cosas que pasan, y los métodos actúan en consecuencia. En un sistema democrático se envía un mensaje a un objeto (eso sí los mensajes pueden ser falsos); en una dictadura (y el programador de un aplicación lo es cuando escribe Query.Close) se llama directamente a los métodos, guste a o no.

Saludos, y a continuar con estas disquisiciones.

[roman]

Posteado originalmente por andres1569

Muchas cosas interesantes


Ok. Ya que insisten si marcsc nos hace el favor pues vamonos a los debtes a que le refute también a andrés1569 sus argumentos :D

// Saludos

[roman]

Gracias!, Ahí voy :p

Para empezar quiero comentar que desde mi punto de vista personal cuando uno comienza a diseñar una aplicación con las técnicas de orientación a objetos (si gustan con o herramientas UML o simplemente haciendo dibujitos en papel) uno no se refiere a un lenguaje de programacón en particular. Por ello pienso que elargumento de que "estamos programando para Windows, utilizando Delphi" no es del todo válido.

Durante el diseño y análisis de la aplicación, si realmente empleamos técnicas OOP (y no digo que yo lo haga así de ordenadito) hablamos de objetos, relaciones entre ellos y los mensajes que se mandan unos a los otros.

En segundo lugar, todo esto del abrigo (y por favor cambien de ejemplo pues aca estamos a 30 grados centigrados :P) tiene un poco de trampa. Cuando llamamos un método de un objeto, no podemos saber, precisamente por el encapsulamiento, de que manera el objeto va a procesar el método. Quizá, al igual que hace Windows, almacene algunas llamadas, o efectos de las llamadas, en alguna cola. Quizá incluso el objeto maneje "threads" internamente para procesar asíncronamente algunas cosas.

El encapsulamiento se da en cualquier caso. No hay mucha diferencia entre estas dos llamadas:


Rectangulo.Paint;
SendMessage(Rectangulo, WM_PAINT)


En ninguno de los dos casos sabemos internamente lo que hara el objeto Rectangulo para procesar el mensaje.

Incluso, ya hablando específicamente de Delphi, muchas llamadas a métodos se traducen en llamadas a SendMessage, allá muy en el fondo del VCL.

// Saludos

[andres1569]

Hola de nuevo:

Ok, Roman, sí es cierto que mi ejemplo lleva algo de truco, nunca sabemos qué se esconde detrás de un método, aunque su nombre sea muy explícito y sea previsible, no vaya a ser que el método PonteAbrigo lo que haga sea ponerse el bañador y echarse a la piscina (así mejor ¿no?, aquí en España ya empieza a hacer calorcito, también).

Roman escribió:

Incluso, ya hablando específicamente de Delphi, muchas llamadas a métodos se traducen en llamadas a SendMessage, allá muy en el fondo del VCL.


Bueno, esto es lo que originó el debate, tú mismo diferencias en este párrafo entre métodos y llamadas a SendMessage (¿cómo no?), o sea llamadas a mensajes, creo que lo que quiso hacer notar Delphi.com.ar era esta diferenciación, puesto que el autor del tema hablaba de lo segundo cuando a la hora de cerrar un Query sólo nos valemos de sus métodos; supongo que Delphi.com.ar quería aclarar esa cuestión, independientemente de que sean muy semejantes ambos términos o de que se puedan utilizar indistintamente en algunas / muchas
circunstancias.

Puesto a pensar en el tema, y siempre mirando la forma en que están implementados en Delphi, encuentro interesante este debate por cuanto te das cuenta de ciertos matices que los diferencian:

- Los métodos que podemos acceder desde fuera del objeto son necesariamente public, mientras que los mensajes pueden disparar indirectamente un método privado o protegido. Un punto a su favor.

- Los mensajes se parecen a las interfaces, puedes invocarlos aunque el objeto receptor no los implemente, sencillamente lo ignorará. No deja de ser otro punto a su favor.

Bueno, sigan hablando ...

[delphi.com.ar]

Estamos volviendo a lo mismo otra ves.... Separemos el tema de los mensajes de Windows de los métodos, que pasa si hablamos de una clase no heredada de TControl, que no tenga ninguna relación con el sistema operativo... Por ejemplo el método Assign de la clase TPersistent. Sin lugar a dudas si repitiendo que "desde el marco de vista te vista teórico, los métodos son la manera de implementar lo que a nivel conceptual es enviar un mensaje a un objeto", si es un mensaje, pero nada tiene que ver con los mensajes de Windows.
Creo que si programamos en Delphi, tenemos que referirnos con el término "mensaje" a los mensajes de Windows, simplemente para evitar confusiones.

Hasta Mañana!

[__marcsc]

Posteado originalmente por andres1569

- Los métodos que podemos acceder desde fuera del objeto son necesariamente public, mientras que los mensajes pueden disparar indirectamente un método privado o protegido. Un punto a su favor.


No acabo de entender esta afirmación....

Si hacemos una analogía y suponemos que en el entorno windows tenemos objetos como los que estamos acostumbrados a manipular en Delphi, los códigos de mensaje que hay definidos y que un objeto es capaz de recibir y ejecutar equivaldrían a los métodos publicos, no? Es decir, la parte pública es la que nos permite interactuar con el objeto.


Los mensajes se parecen a las interfaces, puedes invocarlos aunque el objeto receptor no los implemente, sencillamente lo ignorará

Tampoco acabo de entender eso del todo... A ver, si es lo que estoy entendiendo, un objeto que hereda de una interfaz puede llamar un método que esté definido (pero no tiene porqué ser implementado) por una interfaz padre, produciendo un error en tiempo de ejecución. Del mismo modo, al menos en Delphi, podemos también llamar a un método de una clase definido como abstracto, pero que no tiene porqué estar implementado. Eso producirá también un error en tiempo de ejecución.

Sin embargo, un mensaje se puede enviar, en principio, a cualquier objeto siempre que dispongamos de su Handle, pero en ese caso no hay una jerarquía, definida, no? Es decir, podemos enviar cualquier mensaje a cualquier objeto... (Lo pregunto porqué tampoco conozco muy a fondo la API de Windows)

Saludos.

[roman]

Ya ni pongo citas porque esto se está complicando mucho :) pero...

El hecho de que el VCL implemente métodos mediante mensajes Windows no corrobora el hecho de que métodos y mensajes sean cosas distintas. Como dije (o he implicado) el lenguaje OO habla de mensajes entre objetos pero la forma de implementar estos mensajes es distinta según el lenguaje de programación en particular con que se trabaje. Dado que Delphi y Windows implementan los mensajes entre objetos (y los objetos en sí) de formas distintas, es necesaria una adaptación entre una arquitectura y otra. Esto es precisamente lo que hace el VCL.

Hago énfasis en lo que dije anteriormente. Si pensamos en el ambiente Windows como en un ambiente de objetos (las ventanas), tenemos las tres propiedades principales de OO:

[list=1]
Encapsulamiento - Los detalles de la implementación de lo que hace cada ventana ante un mensaje están ocultos.
Herencia - Mediante el "subclassing"
Polimorfismo - Todas las ventanas reaccionan ante los mismos mensajes: WM_PAINT, WM_CLOSE, WM_MOVE, etc., etc. pero de maneras distintas.
[/list=1]

En el caso de Delphi podemos tener una aplicación con varios formularios, todos ellos heredados de TForm y podemos redefinir el comportamiento del mensaje "Cerrar" redefiniendo el método Close y los detalles de la implementación quedarán ocultos. Más aún podemos mandar este mensaje a cualquier ventana de nuestra aplicación y ésta responderá adecuadamente según el polimorfismo. Todo esto con llamadas al método Close.

Pero, ¿cuál fue la diferencia? Conceptualmente es lo mismo:

Mandar el mensaje "Cerrar" a las ventanas

La diferencia está en cómo se implementa este envío de mensajes pero siguen siendo mensajes de cualquier forma (desde el punto de vista teórico de OO)


Ahora bien, es cierto, lo acepto, que la práctica como programadores de Delphi nos lleva a pensar en "mensaje" como el enviado con SendMessage, pero es sólo eso: usos y costumbres.

Quiero pensar que el estudiante de informática no estará casado con un lenguaje en particular o una metodología específica (aunque tenga unas favoritas), de manera que al estudiar metodologías como OO, será bueno que se acostumbre a pensar en objetos y mensajes, independientemente de los lenguajes que posteriormente utilice. Esto le será de gran ayuda para entender lo que hay en el fondo de las cosas-- entender un sistema de ventanas (por ejemplo) independientemente de con qué arquitectura se implemente. Entender, a fin de cuentas, el funcionamiento esencial de las aplicaciones que desarrolle, antes de siquiera escoger el lenguaje de programación que utilizará.


Y a manera de meterle leña al fuego, pregunto:

¿Qué son los eventos de Delphi?

¿Son métodos? ¿Son mensajes? ¿A qué corresponden en el ambiente Windows?

// Saludos

[andres1569]

Hola:

Me explico. Digo que se puede invocar una acción que no está en los métodos públicos cuando por ejemplo queremos provocar una pulsación de teclado, esta acción no se me ocurre otra forma de hacerla que mediante un SendMessage, o un Perform aplicado al objeto, el cual es interceptado por un método privado o protegido. Hay acciones que sólo se pueden provocar mediante mensajes.

En cuanto a lo de las interfaces lo dije pensando en las interfaces a objetos OLE donde una llamada inválida es ignorada (estaba yo en los cerros de Úbeda pensando en Excel), que no son iguales que las interfaces de Delphi, efectivamente como tu dices éstas pueden fallar en tiempo de ejecución aunque no proteste al compilar.

Buenas noches,

[__marcsc]

Ok, andrés, entendido :)

Respecto a lo que dice Roman, creo que ha dado en el clavo, precisamente hoy hablando con cadetill, lo que hemos sacado más o menos es un resumen:

los mensajes de windows y los mensajes de los objetos Delphi (léase métodos ;)) son en esencia lo mismo, pero dado que son dos "capas" diferentes de soft, su implementación y utilización es distinta. El paralelismo no es completo, pero yo el simil lo veo bastante claro.

Esas dos capas se deben diferenciar, y por tanto, debemos entender que dado que la VCL es una capa más exterior que la de la API, es normal que para implementar sus mensajes haga uso de los mensajes de la capa interior....

Ya se que no es una manera muy metódica de expresarse, pero creo que todos entendemos las mismas cosas pero las expresamos de distinto modo :)

Otra cosa más sobre la encapsulación: Está muy bien, hasta cierto punto, poder despreocuparte de como se implementan según que cosas. Al menos cuando yo empecé con Delphi, no tenia ni idea de como funcionaba Windows ni sabia casi lo que era la API...

Sin embargo, a la que vas avanzando y necesitas hacer cosas más complejas, necesitas implicarte un poco más y descubrir, aunque sea con poco detalle como funciona todo eso tan bonito que ves en la pantalla.... Y luego descubres la API y sus mensajes y cuando llevas un tiempo con eso te das cuenta de que todas esas cosas acaban traduciendose a mensajes...

Pero bueno, paro ya de escribir que me aburro a mi mismo :D

Un saludo.

[delphi.com.ar]

Posteado originalmente por roman
¿Qué son los eventos de Delphi?

¿Son métodos? ¿Son mensajes? ¿A qué corresponden en el ambiente Windows?

Creo que Delphi es uno de los lenguajes más claros para entender este concepto, para Delphi los eventos no son mas que propiedades del tipo "procedure of object", son manejadas como propiedades por el lenguaje y reciben el mismo trato que cualquier propiedad, la única diferencia notable es en tiempo de diseño.
Con respecto al ambiente Windows, un evento de una clase en Delphi no necesariamente tiene que ser causa de un mensaje de Windows, por ejemplo el evento OnChange de un TStringList, lejos está de ser algo propio del sistema operativo. Los mensajes de Windows, son es la manera que tiene Windows de producir eventos para comunicarle a las ventanas los "eventos" sucedidos. Es medio redundante, pero espero que sea claro.


Saludos Foristas!

[Kafu]

Un saludo a todos.
Aunque creo que en lo básico es un tema de semántica, desde mis escasos conocimientos sí se me hace más cómoda una diferenciación entre método y mensaje.
Perdonadme si no soy muy estricto en la terminología. Creo que para quien no se interna a menudo en la vcl, que francamente da miedo, el uso de métodos explicitos es lo que se nos presenta como única opción.
Quiero decir que es más fácil de comprender y controlar la llamada a un método público de un objeto puesto que sabemos qué es lo que va a ocurrir y casi cuándo.
Pero sí me parece que es de alguna manera diferenciable eso, por mucho que internamente se traduzca en mensajes, con por ejemplo la creación de un mensaje nuevo (no tiene que ser de windows como ya se ha comentado) que se lance para que objetos preparados con métodos "oreja" reaccionen en consecuencia. Esta reacción es menos previsible, no es una llamada explicita.

[roman]

Kafu llegó y dijo
Un saludo a todos.
... creo que en lo básico es un tema de semántica,
desde mis escasos conocimientos sí se me hace más cómoda una diferenciación entre método y mensaje.

Tienes razón, es una cuestion de semántica y ciertamente cada quien utilizará la terminología con la cual se sienta más cómodo.

Kafu llegó y dijo

Perdonadme si no soy muy estricto en la terminología. Creo que para quien no se interna a menudo en la vcl, que francamente da miedo, el uso de métodos explicitos es lo que se nos presenta como única opción.
Quiero decir que es más fácil de comprender y controlar la llamada a un método público de un objeto puesto que sabemos qué es lo que va a ocurrir y casi cuándo.

También esto es correcto. El trabajo del VCL es lidiar con las entrañas del Api de Windows para proporcionarnos una interfaz más sencilla y acorde a la semántica de Delphi. En una gran cantidad de ocasiones el programador no tiene que entender las entrañas del VCL ni del Api de Windows, de lo contrario estaríamos mejor programando en C.


Posteado originalmente por Kafu
Pero sí me parece que es de alguna manera diferenciable eso, por mucho que internamente se traduzca en mensajes, con por ejemplo la creación de un mensaje nuevo (no tiene que ser de windows como ya se ha comentado) que se lance para que objetos preparados con métodos "oreja" reaccionen en consecuencia. Esta reacción es menos previsible, no es una llamada explicita.
Aquí es donde ya difiero pero el punto es que no me he dado a entender bien. Yo no estaba tratando de establecer un paralelismo entre Windows y Delphi. Uno y otro son dos cosas muy distintas. Uno es un sistema operativo y el otro un ambiente de desarrollo y un lenguaje de programación.

Lo que yo trato de establecer es:

Desde el punto de vista teórico de orientación a objetos, los objetos se mandan mensajes unos a los otros.

En la práctica, distintos sistemas implementarán los objetos y el envío de mensajes de formas distintas.

Delphi y Windows son dos ejemplos de implementación de objetos y ambos lo hacen de maneras muy distintas

El hecho de que una llamada a un método en Delphi sea un mensaje desde el punto de vista OO, no se debe a que internamente se traduzca a una llamada a SendMessage del Api de Windows, sino a que le estamos comunicando a un objeto lo que deseamos hacer con él.

La razón de que Form1.Close, desde el punto de vista de OO, sea un mensaje, no se debe a que se traduzca en una llamada a SendMessage(Form1.Handle, WM_CLOSE, 0, 0). Se debe simplemente a que le estamos comunicando al objeto Form1 que se cierre.

Esto es, OO establece el concepto de mensajes desde un punto de vista conceptual y no se preocupa de como estos mensajes se implementen porque de hecho OO no se refiere a ningún lenguaje en particular.

Por otro lado, si bien Delphi y Windows son sistemas muy distintos y cada cuál resuelve las cosas a su manera, Delphi debe comunicarse con Windows. Dado que hablan lenguas distintas (implementan OO de formas distintas) debe haber una traducción. El traductor (al menos para la parte visual) es justamente el VCL.

http://comenius.cele.unam.mx/roman/mensaje.gif

Y lo cierto también es que, al programar en Delphi, debido a que en ocasiones debemos lidiar con el Api de Windows, conviene por razones prácticas distinguir llamadas a métodos (implementación Delphi de mensajes OO) de mensajes a ventanas (implementación de Windows de los mensajes OO)

// Saludos

[delphi.com.ar]

Posteado originalmente por roman
al programar en Delphi, debido a que en ocasiones debemos lidiar con el Api de Windows, conviene por razones prácticas distinguir llamadas a métodos

Ese fue el comienzo del debate, en lo que creo que estamos todos de acuedo!

[roman]

delphi.com.ar llegó y dijo
Ese fue el comienzo del debate...
No precisamente, en realidad fué:

Hace varias lunas delphi.com.ar dijo:

Bueno, ante todo aclaremos que estas confundiendo los temas, no estas enviando mensajes, estas queriendo ejecutar un método propio de una clase, tené en cuenta que los mensajes solo se los puedes enviar a las ventanas, en Delphi todos los componentes heredados de TControl y alguno otro en particular que cree una ventana.


Tu afirmación fue categórica y negó los principios de OO sin aclarar que te referías a los usos y costumbres pues, tal como

marcs indicó

es cierto que existen los dos significados...

- Desde el punto de vista cuotidiano del programador windows, entendemos que enviar un mensaje es ejecutar una llamada a la API de Windows.

- Sin embargo, cuando se estudia la orientación a objetos desde el punto de vista teórico, lo que nos venden ( o al menos me vendieron a mi) es que los métodos son la manera de implementar lo que a nivel conceptual es enviar un mensaje a un objeto.


Y el segundo significado no sólo es el que establece la teoría de OO (aunque la práctica use otra terminología), sino que es válido e importante para quienes se encuentren estudiando orientación a objetos.

// Saludos

[delphi.com.ar]

Tenés razón en que fué un no categórico, pero como vos bien dijiste, conviene por razones prácticas distinguir llamadas a métodos (implementación Delphi de mensajes OO) de mensajes a ventanas (implementación de Windows de los mensajes OO)
Creo que en eso estamos todos de acuerdo.

Saludos y Feliz Cumpleaños! :D

[roman]

Posteado originalmente por delphi.com.ar
Saludos y Feliz Cumpleaños! :D

Muchas gracias d.c.a!

Me parece que sería buena idea declarar cerrado este debate para no empantanarnos en él :)

// Saludos