OI is clearly a good thing. But we're making a moutain out of a molehill here. Achieving this just isn't that complicated.
There is just one simple problem that needs to be addressed, what I call the component problem: what are the mechanisms and infrastructure by which software authors can deploy and version code in binary form and yet be robust in the face of varying and versioning clients?
I believe the component problem is now solved; I'll elaborate of course in great depth at the workshop. (But see also the first paragraph above.)
Given a solution to the component problem, the problem of OI can be addressed by setting up a reverse client-server relationship in which the client C of the original server S gives to said server an instance of a component that S is to use as his implementation of certain services, the latter being completely determined by the semantics of the contract / interface through which the component is passed to S by C.
Example: allow C to provide the storage services that S is to use to
store its persistent state. C implements the following interface:
S implements the following interface by which an IStream instance is passed
to it.
interface IStream {
read(...)
write(...)
etc
}
Aside: I see little point in calling these 'meta' interfaces: this is sort
of parameterization in practice becomes so common that trying to thing of it
as moving to a higher semantic level is confusing and not
warranted. IPersistStream is not an interface on S's class, for example.
interface IPersistStream {
load(IStream*)
save()
etc.
}
The "enhancing the compiler's layout of objects" type examples are just a component problem involving an installable piece in the compiler.
I look forward to meeting you all next week.
Back to Alphabetical List of Responses
(Last Revised October 1994)