Re: IMRs again (was Re: Comments on the baboon plugin spec)
- From: Mike Coleman <mkc sky net>
- To: Elliot Lee <sopwith redhat com>
- Cc: orbit-list cuc edu, gnome-components-list gnome org
- Subject: Re: IMRs again (was Re: Comments on the baboon plugin spec)
- Date: 17 Sep 1998 22:27:45 -0500
Elliot Lee <sopwith@redhat.com> writes:
> The program using an object (aka client, aka application) has the big
> picture of how that object will be used, how that object (aka
> implementation) will relate to other applications, etc. That knowledge is
> impossible for the object implementation to know, because a basic premise
> of the OO model is being able to reuse an object implementation.
>
> The client knows exactly what programmatic context the object will be used
> in, so therefore the client is the only entity qualified to make the
> decision of how the implementation is activated.
My first thought would be that the person that "sets up" the client should be
the entity making the decision, rather than client code itself. As an
analogy, when I run 'xterm', *I* decide between several ways it might connect
to an X server. The 'xterm' code doesn't care, though, and doesn't contain
any knowledge about which might be better or worse.
> Furthermore, I don't see how it _removes_ flexibility from the person
> writing the object implementation (which you mean by "object developer", I
> think). Elaborate...?
I'm not sure if this is what was meant, but it seems like having 'dlopen'
calls in client code would be ugly--sort of like hard-coding the value of
DISPLAY in 'xterm'.
Whatever the solution is, it would be nice if the client code wouldn't have to
be touched at all, and all of these decisions were distilled out and put
elsewhere.
(Caveat: I'm still trying to wrap my brain around this CORBA thing...)
--Mike
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]