Re: CORBA question

[Felix Bellaby <felix pooh u-net com>]

Elliot Lee writes:
 > On Wed, 9 Dec 1998, Felix Bellaby wrote:
 > > You do not have more than one set of code that implements a widget 
 > > in gtk or a class in C++. What you have instead is object inheritance. 
 > 
 > That is because those object systems do not allow interface-only
 > inheritance, which is what CORBA inheritance is. You're trying to fit
 > CORBA into your view of existing program-local object systems and make it
 > work the same way.

Every object system allows interface-only inheritance. All you 
need to do is overload all the functions that you inherit.

CORBA is capable of limited non-interface-only inheritance. It is
sometimes possible to call operations on the base class within
the child class. For example, when both classes are implemented 
within a single server.

However, this is just being pedantic. All that I want is
CONCEPTUAL inheritance. The operations in a child class should
resemble the operations in the base class. How you implement 
this functional resemblence is irrelevent to the object client.

Applets do resemble one another. However, they are also distinct: 
the fish applet is not identical to the bussign applet. At this 
conceptual level, forgetting all the implementation details, it 
seems appropriate to treat the fish and bussign applets as
variations on a common base interface.

What else is IDL inheritance supposed to mean ? 

 > > I think the object inheritance approach is better becuase it uses a
 > > CORBA core feature (the interface repository) to access the servers
 > > rather than using an API which is completely outside CORBA (the
 > > server_id). It is every bit as flexible and more distributed.
 > 
 > I think we should all eat green eggs and ham, samiam.
 >
 > The only reason the interface repository would become involved with your
 > scheme is because it would become required in order to do any GNOME server
 > activation stuff and still get generic instances. More dependencies mean
 > slower & less reliable. Ergo, it sucks.

The interface repository arrangement that I am proposing does not
require that you use the interface repository to activate servers. 
You can even activate generic servers for base interfaces without
going to the repository.

For example, let us say that the "gen_util_applet" is the applet
that we want to start when we do a search through goad for the
"IDL:GNOME/applet:1.0" repo_id. All we need to do is give the
"gen_util_applet" the repo_id "IDL:GNOME/applet:1.0". We give the
other applets different distinct repo_ids.

It is true that under my scheme you would have to go to the interface 
repository to find the list of servers which implement an interface. 
However, under your scheme you have to go the interface repository
and goad to get a complete list of servers. Goad only gives you a 
list of servers which exactly implement a named interface. It misses 
out any servers which implement interfaces that inherit from the 
interface.

Where is the advantage in your approach ?

Felix