On 04/04/2011 2:55 AM, Jonathan S. Shapiro wrote: > We have already agreed that some form of member function notion is > useful. A member function is one that is trusted to maintain the > integrity constraints of a data structure. Note that the existence of > member functions tacitly implies the notion of a "this" pointer.
I know you're convinced of this, but I still don't see it. The priviledge of your access is a question of your visibility on the internals. Certain implementations of type classes have a degree of visibility by default which would *seem* to make it at odds with integrity constraints, particularly Haskell's global type class resolution. And yet, you can write robust code that enforces integrity constraints just fine in Haskell, even programs featuring a great deal of mutation. Clearly then this is not a property of type classes per se, but implies the need for some abstraction that lets you speak meaningfully about encapsulation (generally existential types). If BitC's resolution is still lexical, visibility on internals is even less of a problem. But, we've discussed this all before, and I failed to convince you then, so I'm not sure what I can say except to point to Haskell as a counter-example to the assertions made here. For privileged access to internals, you simply make the type abstract in the exported module, and only functions exported from that module have visibility on the internals (essentially, it has existential type). > I think we agree that the notion of "interface" corresponds much better > to the notion of "contracts" than inheritance does. Type classes have inheritance too, on both interface and implementation [1]. They've also explored static contract checking in Haskell [2]. I'm not sure what sorts of contracts you're considering, but I have yet to encounter an invariant that wasn't more easily specified, enforced and extended in a functional language than an OO language. > 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. You're casting one of the worst parts of OO as a benefit. Post-hoc interface implementation is a feature, not a bug; the bug is the inability to declare a type as implementing an interface after the fact. Go made this same mistake. I can't even count the number of times I've had a type that implemented an interface structurally, but did not declare that interface, which then requried me to build a whole new wrapper abstraction which simply delegated calls. > * 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. Your interfaces are essentially type classes hard-coded with an existential type for the first element. We clearly have two separate abstractions at work here though, ie. encapsulation + overloading, not one. Sandro [1] http://www.haskell.org/haskellwiki/OOP_vs_type_classes#Inheritance_between_interfaces [2] pauillac.inria.fr/~naxu/research/HaskellContract.pdf _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
