In another thread, we had a discussion under the general heading of "dynamic vs static permissions". The idea being that a Java object has a set of methods (it's dynamic permissions), while an interface gives access to a subset of those (the static permissions of the interface). It occurred to me this morning that this intuition actually doesn't hold for the notional BitC interface proposal.
Underneath the dynamic vs. static discussion was a hidden assumption that we were operating within something like the Java "implements" notion of interfaces. In that notion, the methods that are accessible through an interface (a) are a subset of the methods provided by the class, and (b) *must* be methods of the class. If we decide to adopt a similar syntactic pattern in BitC, both of those assumptions will hold *where implements is used*. But the description of interface construction that I gave earlier in this thread actually doesn't have *either* of those properties inherently. The interface constructor, as I have sketched it, takes a state object and some number of procedure objects where the type of the first argument agrees with the type of the state object. The proposed definition is simply an existential close operation that works over multiple procedures simultaneously. And now that I think about it, it needs to be tweaked so that one interface method can call another, but that's straightforward. Those procedures are not, in any way, required to come from any "underlying" object. They are simply procedures. They can even be procedure literals (lambdas). In consequence, the relationship between a BitC interface and its "underlying object" is not a "function subsetting" relationship. As one example, an interface can provide functionality that the underlying object never provided. This will actually tend to happen when interface definitions and their conversions are provided by third parties. As a second example, the "state" over which an interface closes may not be a singleton reference to an underlying object. The encapsulated value may be a composite type containing references to a number of objects. In some cases the interface may perform its function by relying on *multiple* underlying objects. I think we can still say in a sensible way that a BitC interface is a wrapper, but the choices about what it wraps are a lot richer than the corresponding notions in Java or C#. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
