Lambda the Ultimate

inactiveTopic Type Safety in a Dynamically Extensible Class Library
started 10/20/2003; 12:55:25 AM - last post 10/21/2003; 1:52:59 AM
Dan Shappir - Type Safety in a Dynamically Extensible Class Library  blueArrow
10/20/2003; 12:55:25 AM (reads: 5872, responses: 5)
Type Safety in a Dynamically Extensible Class Library
via Don Box's Spoutlet

A document from 1988 that is a part of the early work leading to OLE and COM.

In this paper I consider the requirements for run-time representation of classes and protocols. These requirements derive from the objectives of integration of applications, and an open-ended library of object types. Following the example in BillG's memo of Sept 22, the specific intent is to permit a user to install code that implements a new type of object (such as an image) into his library, and immediately use objects of that type with his existing applications such as word processors.
Posted to history by Dan Shappir on 10/20/03; 12:57:02 AM

Ehud Lamm - Re: Type Safety in a Dynamically Extensible Class Library  blueArrow
10/20/2003; 1:11:21 AM (reads: 310, responses: 0)
The issue being discussed in this memo is of fundamental importance. Dynamic linking, in a multi-language environment, is going to be at the corner stone of any software architecture worth its salt.

It's to Microsoft's credit that they try to tackle this problem head on, even if one doesn't like the currently avialable solutions.

LtU readers will be reminded of the PL as OS theme, which is just another way of looking at this same problem.

Ziv Caspi - Re: Type Safety in a Dynamically Extensible Class Library  blueArrow
10/20/2003; 2:02:13 PM (reads: 237, responses: 3)
What do you mean "try"? Hardly any Microsoft business product comes with a full set of COM-based programming model, just like T.W. envisioned. VB (yeah, the same language which apparently is closer to Haskell than I first realized) can attribute at least 50% of its success to being a smart front-end to COM.

Ehud Lamm - Re: Type Safety in a Dynamically Extensible Class Library  blueArrow
10/20/2003; 2:11:15 PM (reads: 246, responses: 2)
Is there a typo in your second sentence? Should it be "almost all" instead of "hardly any"?

By "try" I mean that COM etc. don't seem to me to be the ultimate solution to the general issues I mentioned (but I am not an expert on these technologies, so it's hard for me to be very specific).

One thing that comes to mind is execptions in the CLR. I cannot accept that "checked" exceptions shouldn't be there, simply because that's what the CLR team decided. I think the issues are more subtle.

Same goes for support for cross-language design by contract facilities (a favorite of mine).

But, like I said, I think Microsoft is a leader in this area, and I applaud its efforts.

Dan Shappir - Re: Type Safety in a Dynamically Extensible Class Library  blueArrow
10/20/2003; 2:41:03 PM (reads: 253, responses: 1)
While CORBA predated COM (Apple's OpenDoc maybe also did, I'm not sure) COM was, and I think still is, the most deployed component technology. Moreover, despite it's various shortcomings, it proved to be an instrumental technology for Microsoft. It has also delivered on many of its promises: more-or-less language neutral (almost every PL implementation on Windows supports COM to a greater or lesser degree), location neutral (in-process, out-of-process, and sometimes even across a network). Indeed, the abundance of COM components is the real proof that component technology does work.

All this does not mean that COM was without its faults:

  1. Half-hearted attempt at a type description facility (TLBs)
  2. A distributed technology that couldn't really span firewalls.
  3. No standardized support for exceptions of any kind.
  4. The weird dispatch interface and derivatives.
  5. Very very limited support for versioning
  6. An unwieldy substitute for the lack of implementation inheritance (Aggregation)
  7. Overly complex host/component negotiations that involved dozens of interfaces.
  8. Complex yet limited and often misunderstood security model.
the list goes on.

NET and the CLR solve quit a few of these issues, but not all of them and at a price. I'm not sure all the issues are solvable.

Same goes for support for cross-language design by contract facilities

This is a good example. How do you support design by contract as a standard part of the CLR when many (most?) .NET-based PLs don't implement or support DBC? Microsoft is already forcing many PLs to undergo significant adaptations in order to fit into the .NET environment. You do need to draw the line somewhere (this is not to say that I'm against DBC, indeed I'm very much for it).

Ehud Lamm - Re: Type Safety in a Dynamically Extensible Class Library  blueArrow
10/21/2003; 1:52:59 AM (reads: 222, responses: 0)
How do you support design by contract as a standard part of the CLR when many (most?) .NET-based PLs don't implement or support DBC?

Sure. I don't think it's just "Microsoft's fault". Software development still has a long way to go. Of course, there are ways one could in fact support DBC even if not all CLR languages support DBC.