Anterior
 Volver
 Siguiente

 
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;



 Anterior
 Volver
 Siguiente