Come to think of it, how does an interface differ from a full blown object then? And correspondingly, how does the "Castable" type class differ from a "Coercion" type class for implicitly coercing between arbitrary types?
On Sun, Jul 6, 2014 at 11:38 AM, Jonathan S. Shapiro <[email protected]> wrote: > 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#. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
