On 4 April 2011 16:55, Jonathan S. Shapiro <[email protected]> wrote: > I think we agree that the notion of "interface" corresponds much better to > the notion of "contracts" than inheritance does. > > I believe - and I *suspect* we will agree - that there are two substantive > differences between interfaces and type classes: > > An interface must be planned for by the developer of the object, because > "this object implements interface I" is part of its declaration. This is not > true of type classes.
I take it you are defining the term "interface" here to preclude existential typing; this needs to be said because I have not seen it used consistently that way. http://www.canonical.org/~kragen/isinstance/ uses the term in the manner I would use it. I don't see why a sensible interface concept must be part of the type declaration, post-hoc existential casts can be shown to be typesafe in all sorts of reasonable situations (iirc, it is quite idiomatic in Scala). > An interface (at least in Java and C#) has an implicit "this" pointer, and > its members can therefore have integrity-privileged access to the underlying > object. This is not true of type class methods. Isn't it? Typeclass instance definitions, when placed in the module defining the data type, may be functions (or call functions) that have privileged access to the data type, can't they? > To evaluate the difference more clearly, I propose that we "break" the > strong tie between interfaces and objects. Let us instead define an > interface as a collection of functions sharing a common (possibly empty) > closure. This is mostly convenient because it lets us finesse the > object/closure distinction for a moment, and it admits the possibility that > interfaces might be constructed in post-hoc form. And then presumably to leave the access control in the hands of some orthogonal mechanism? -- William Leslie _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
