FTP | CCD | Buscar | Trucos | Trabajo | Foros |
#1
|
|||
|
|||
El operador as
Hola
El operador as lo hago para hacer un cast objecto as clase por ejemplo
vale, esto parece claro, pero lo que quiero saber es muy sencillo. Es lo mismo poner (F as TFProveedores).MiProcedure que poner TFProveedores(F).MiProcedure. Es sólo eso, saber si los dos tipos de cast son equivalentes en todos los casos y sólo son dos formas de escribir lo mismo. Un saludo |
#2
|
||||
|
||||
Cuando hace un typecast tienes que estar seguro de que los dos tipos son compatibles, en en caso del operado "as" es el mismo el que se encarga de hacer esa comprobación.
Es decir:
Equivale a esto:
Como ves hacen lo mismo, pero "as" primero hace una comprobación. |
#3
|
||||
|
||||
Hola,
Y yo que pensaba que tenía que ver con el tipo de error, o sea, excepción, que era generada en un caso uno de los "sistemas" y no por el otro... No voy a ponerme a rebatir al maestro Seoane, pero, ¿de qué sirve esta "condición"? Lo pregunto sin ánimo de molestar, sino, sinceramente, a ver si alguien puede sacarme del "dilema".
¿De qué sirve la condición, si, pase lo que pase, se avanzará hasta la línea siguiente? ¿Acaso debería atraparse la posible excepción? ¿No sería mejor usar el operador "is"? ¿Me estaré volviendo loco? Actualización: Acabo de comprobar que, usando el operador "as", se obtiene una excepción "EInvalidCast", mientras que, usando "el tipo" directamente, se obtiene una violación de acceso. Última edición por dec fecha: 02-01-2008 a las 16:17:20. |
#4
|
||||
|
||||
Cita:
Me explico, si tenemos esto:
y "Objeto" no es de la clase TEsteObjeto (o una descendiente), se genera una excepción y la siguiente linea de código a esta no se ejecuta (como ocurre con todas las excepciones). ¿no es así? |
#5
|
||||
|
||||
Hola,
Pues sí... así es... pero, yo no llamaría a eso una "condición", entendiendo como condición algo como esto:
No sé. Es que, tal como yo entendí lo que dijiste (mejor dicho, acaso podría entenderse, por lo que dijiste) que el mismo "as" hará que el "asunto" se ejecute si se cumple la "condición", pero, es que no parece que sea así: se levanta una excepción, la condición "no la evita". Pero, puede que esté desbarrando, ¿eh? Si lo pienso un poco más, puede que lleves toda (no parte de) la razón, porque la "condición" impide que se siga adelante, y, por tanto, se obtenga una violación de acceso, como ocurre en el otro caso, mas, ¿no es ya la "EAccessViolation" un tipo de excepción? Lo dicho, algo se me escapa en este asunto. Acaso es mejor una que otra excepción... lo ignoro ahora mismo. Una cosa está clara: son distintas excepciones. Última edición por dec fecha: 02-01-2008 a las 16:26:04. |
#6
|
||||
|
||||
Cita:
No tengo delphi a mano, pero se me ocurre que podes comprobarlo de manera sencilla (por favor, corregí vos por mi los errores de sintaxis que pudiera haber:
Espero que funcione como yo lo espero , si no, ya veremos cuando tenga un delphi a mano. Hasta luego.
__________________
Juan Antonio Castillo Hernández (jachguate) Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate |
#7
|
||||
|
||||
Hola,
Creo que funciona tal como esperas Juan Antonio. Sin embargo, sigue sin quedarme claro todo este asunto. No creo que "la gracia" esté en que algo así no compile, directamente:
En esto me debe pasar como en tantas cosas, que, como no las conozco, ignoro su posible utilidad... |
#8
|
||||
|
||||
Algo así compilaría... la ventaja es que estas seguro de obtener una excepción en caso de no corresponder la clase.
Por ejemplo:
Hasta luego.
__________________
Juan Antonio Castillo Hernández (jachguate) Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate |
#9
|
||||
|
||||
Hola,
Eso digo. Pero por el tema de tener una excepción más oportuna, es decir, que esto otro:
Podría ser problemático, porque el "EAccessViolation" podría venir de otro lado, no del "cast" en cuestión. ¿No? Aún así me sigue sin entrar lo de la "condición" de que hablaba Seoane. ¿Dónde está la condición? En ambos casos se produce una excepción, salvo que son distintas excepciones. ¿No? Pero, si uno quiere una condición tiene que recurrir al operador "is", ¿o me equivoco? |
#10
|
|||
|
|||
Cita:
El (objeto as TClaseCualquiera).procedimiento es lo mismo que hacer TClaseCualquiera(objeto).procedimiento. El as no control que el objeto que se le pase sea de la clase adecuada, antes hay que preguntar con el "is". El código del botón1 da error en ejecución, el 2 no. Saludos |
#11
|
||||
|
||||
Cita:
Cita:
Hasta luego.
__________________
Juan Antonio Castillo Hernández (jachguate) Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate |
#12
|
||||
|
||||
Hola,
Cita:
Cita:
|
#13
|
||||
|
||||
La idea es hacer que se produzca un EAccessViolation, pero no en la línea donde se hace el cast, sino en la siguiente. ¿Podes comprobarlo?
Si se quitase esa línea, no habría EAccessViolation, al menos no en ese punto, sino en cualquier otro que tratase de usar la propiedad Lineas del componente creado.... como dije, es algo que he hecho rápidamente y sin delphi, pero la idea es esa. Cita:
Hasta luego.
__________________
Juan Antonio Castillo Hernández (jachguate) Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate |
#14
|
||||
|
||||
Hola,
Sí; el ejemplo que preparaste funciona tal como esperas. Es decir, que la violación de acceso no se produce en el "cast", sino el la siguiente instrucción, que, de no existir, evitaría dicha violación de acceso, por el momento... Yo también estoy de acuerdo en que la conclusión de que el asunto estribaba en la diferencia de excepciones no era del todo correcto, o no se elaboró en su momento de la misma forma que se ha hecho en este hilo, gracias, en buena medida, a tu ejemplo. |
#15
|
||||
|
||||
Me alegra que te sea de utilidad... y mas me alegra que cumpliese su cometido sin haberlo podido probar yo antes... veo que mi comprobador interno de sintaxis va mejorando...
hasta luego.
__________________
Juan Antonio Castillo Hernández (jachguate) Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate |
#16
|
||||
|
||||
¡Hola a todos!
Vaya lío con esto del operador As. Primero que nada, va mi sugerencia de utilizar el término molde de tipo para referirse a "type cast". Como ya lo aclaró Antonio, el molde de tipo con el operador As, presenta dos verificaciones de seguridad; una de compilación y otra en tiempo de ejecución. Al compilar se verifica que el tipo de dato usado y el tipo de dato declarado del objeto sean clases con relación jerárquica lineal (padre-hijo, abuelo-nieto, misma clase, etc., pero no tío-sobrino, primo-primo, etc.). En tiempo de ejecución, se realiza una verificación de polimorfismo: que el objeto sea de la clase indicada, de una clase derivada de ella o un puntero nulo (Nil). Mientras que un molde de tipo clásico (yo los conocía desde Turbo Pascal), al estilo "Clase (Objeto)", no impide que el programa compile y se ejecute la sentencia donde aparezca tal expresión. Pero eso sí, el resultado puede ser impredecible si no estamos completamente seguros de lo que estamos moldeando. Me permito añadir aquí una humilde traducción al español de lo que dice la ayuda de Delphi sobre el operador As: Cita:
Al González. |
#17
|
||||
|
||||
Cita:
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
#18
|
|||
|
|||
Cita:
Saludos |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Operador LIKE | eldiegofg | SQL | 2 | 25-08-2007 00:30:59 |
Operador LIKE en access | maurogambo | Tablas planas | 5 | 06-09-2006 15:20:42 |
Operador IS | Aztaroth | C++ Builder | 8 | 04-08-2004 15:44:27 |
Operador *= | febito | SQL | 1 | 09-06-2004 22:26:43 |
Operador @ | Tanix | PHP | 2 | 27-10-2003 11:07:14 |
|