Asunto: Re: Comentarios sobre el modelo de componentes CORBA
Fecha: Thu Jan 20 10:09:55 2000
De: Diego Sevilla Ruiz <dsevilla@ditec.um.es>
Hola a todos:
Rafael Corchuelo Gil wrote:
> Hola a todos:
>
> En más de una ocasión me he planteado la misma pregunta que ha realizado
> Diego y, a forma de pensamiento en voz alta, creo que una razón con los
> pies en el suelo puede ser la siguiente:
>
> Supongo que a la hora de incorporarlas en una herramienta de verdad (no en
> una de laboratorio) suelen aparecer innumerables pegas que hacen que,
> aunque en la teoría las ideas queden bastante claras, en la práctica
> resulten difíciles de implementar. Por ejemplo, hablando de C++, se
> conocen muchas técnicas para conseguir que el usuario no tenga que indicar
> de forma explícita si una rutina es virtual o no y otras para evitar la
> tabla de métodos virtuales que son fuente de ineficiencia en aquellas
> aplicaciones en que el número de llamadas a métodos es crítico. No
> obstante los compiladores de C++ siguen obligando, al menos los que yo
> conozco, a colocar cuidadosamente la palabra virtual.
>
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?
>
> En este caso me parece que puede ocurrir algo similar y que entonces en la
> propuesta final del modelo de componentes CORBA han decidido cortar por lo
> sano e ir por la vía más rápida: Se especifica de forma explícita qué es
> local y de esta forma las
> herramientas con las que trabajamos pueden tratar esos casos de forma
> especial. De esta forma se pueden aplicar técnicas como las descritas en
> el artículo pero de forma ad hoc, sólo cuando se sabe que hay que
> aplicarlas.
>
> A los problemas que apunta Diego yo añadiría uno más: Dificultad de
> reutilización. Si mañana descubrimos que nos hemos equivocado y que algo
> que hemos declarado local resulta que tiene que ser global, entonces
> tendremos que ir cambiando las llamadas a ORB::resolve_local por las de
> siempre.
>
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.
>
> Saludos
>
Igualmente.
diego.
--
Diego Sevilla Ruiz -- http://www.ditec.um.es/~dsevilla/
Departamento de Ingeniería y Tecnología de Computadores
Facultad de Informática. Universidad de Murcia
Campus de Espinardo - 30080 Murcia (SPAIN)
Tel.: +34-968-367570
E-mail: dsevilla@ditec.um.es
$_="\\l/) (>". "_'\n<";@@= /.|\n/g;$_=
"\@". "\007f". "DDq". "DD5". "\204".
"\@". "DT4CE". "D54E". "DD". "\244".
"\021". "dBDTC". "\010DD". "\200\$FD\024".
"GDAG". "DAGDT". "CqI";$c =0;$p =5;for$q
(/./g) {$q= ord$q; for(a, b){$z[$c]
=$@[$p+=($q&15) -4];$q>>=4;$c+=33 ;$c>98 &&($c-=98);}};print@z;