Asunto: RE: Comentarios sobre el modelo de componentes CORBA
Fecha: Fri Jan 21 09:29:22 2000
De: "Rafael Corchuelo Gil" <corchu@lsi.us.es>
This is a multi-part message in MIME format.
------=_NextPart_000_0080_01BF6377.E8D1E0F0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Hola a todos:
> (Diego)
>Una curiosidad: ¿Se puede hacer esto cuando ya se tienen compilados
algunos
>módulos C++? Me refiero a que es sencillo, a partir del análisis completo
del
>código, delimitar qué métodos deben ser virtuales y qué métodos no; pero
no
>resulta tan fácil hacerlo si se cuenta con código ya compilado en módulo
>objeto. ¿Se consigue también en este caso?
Todo esto está bastante desarrollado en el mundo Eiffel, en dónde se ha
alcanzado un nivel de optimación del código generado que ya me gustaría
alcanzasen los compiladores de C++ que conozco. En cualquier caso, este
tipo de optimaciones se suelen aplicar tan sólo en la versión final del
programa puesto que, al menos hasta donde yo sé, requieren de un análisis
global del programa. En el compilador de Eiffel que utilizo esto no se
puede hacer si lo único que tienes es un .obj. Tampoco puedo decir qué
pasa si estás usando una biblioteca comercial con la que no te dan el
código fuente porque no utilizo ninguna. Si alguien tuviera experiencia
con el uso de estas bibliotecas en Eiffel le agradecería que me contase si
sigue siendo posible el análisis.
>En esto tienes razón. Se debe ser muy cuidadoso en identificar y definir
los
>interfaces locales para evitar que en algún momento se puedan (o se deban,
>por cualquier tipo de exigencia) convertir en no-locales.
Claro, pero lo que ocurre es algo parecido a lo que comentaba en el caso de
la palabra virtual: Puede ocurrir que desarrolles varios trabajos
utilizando un interfaz local y al tercero te des cuenta de que realmente
necesitas que no lo sea. Pero permitidme injerir en este punto un trocito
de otra carta de Antonio Vallecillo.
> (Antonio Vallecillo)
> En resumen, no es solo cuestión de una política a seguir durante el
> "deployment" de los componentes de la aplicación, o de reparto de cargas,
> sino de poder especificar unívocamente, durante la fase de diseño (i.e. a
> nivel de interfaz o IDL), la semántica concreta de una invocación.
Si no me equivoco, Antonio, tu idea es que sea el diseñador el que a partir
de una interfaz, digámoslo así, general decida convertirla en local en
algún proyecto particular una vez analizadas las características del mismo.
Corríjeme si te he interpretado mal, pero, en caso de que te haya
interpretado bien, ¿no verías más interesante el desarrollar al máximo
algunas técnicas al estilo de las que he comentado de Eiffel de forma que
esto se pueda hacer de la forma más automática que resulte posible? En
este sentido parece que las ideas del artículo que citaba Diego (que por
cierto, no lo conocía hasta que él nos dio el puntero) pueden resultar
bastante útiles. Por supuesto, como ya has comentado no como solución
general, pero sí adecuada en algunos casos. Es que yo soy partidario de
que todo lo que pueda hacer el ordenado él solito lo haga sin que yo tenga
que preocuparme.
El problema que planteas de las llamadas "oneway" no me había ocurrido,
pero sí, a la hora de hacer las "colocaciones" habría que ser cuidadosos en
estos casos, aunque la idea que apunta Diego podría ser la más sencilla
para resolverlo (¡hasta que se acabe el pool de hebras!).
Saludos Sevillanos
Corchu
------=_NextPart_000_0080_01BF6377.E8D1E0F0
Content-Type: text/x-vcard;
name="Rafael Corchuelo Gil.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="Rafael Corchuelo Gil.vcf"
BEGIN:VCARD
VERSION:2.1
N:Gil;Rafael;Corchuelo
FN:Rafael Corchuelo Gil
ORG:Universidad de Sevilla. Facultad de Inform=E1tica;Lenguajes y =
Sistemas Inform=E1ticos
TITLE:Profesor Asociado
TEL;WORK;VOICE:+34 95 455 27 70
TEL;WORK;FAX:+34 95 455 71 39
ADR;WORK:;Despacho 1.25;Avda. de la Reina Mercedes =
s/n;Sevilla;Andaluc=EDa;41.012;Espa=F1a
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Despacho 1.25=3D0D=3D0AAvda. de =
la Reina Mercedes s/n=3D0D=3D0ASevilla, Andaluc=3DEDa =3D
41.012=3D0D=3D0AEspa=3DF1a
URL:http://www.lsi.us.es
URL:http://www.lsi.us.es
EMAIL;PREF;INTERNET:corchu@lsi.us.es
REV:20000120T175421Z
END:VCARD
------=_NextPart_000_0080_01BF6377.E8D1E0F0--