On Tue, Feb 8, 2011 at 7:21 AM, Sandro Magi <[email protected]>wrote:
> On 2011-02-08 2:47 AM, Jonathan S. Shapiro wrote: > > Further, I'm coming to think that a (seemingly) independent issue may > > push in this direction as well. We've concluded that the notion of > > "readonly" and "mutable" on objects are integrity issues rather than > > access issues. The inference is that we need some sort of permission > > system that distinguishes "caller" procedures from procedures tasked > > with maintenance of integrity (which are generally member functions). > > What will happen if we head down this path is that the mere /existence/ > > of member functions will, in effect, push us in the direction of > > single-variable type classes. > > I don't see why you can't have both. Multiparameter type classes can't > violate encapsulation, since that would violate type safety. > It is true that type classes do not violate type safety, but this misses the point. Member functions have a special relationship to their class, because they can access private/protected (therefore encapsulated) state. > "Member functions" are simply type classes that were defined in the same > module/scope as the type itself, and so have full visibility on its > internals (assuming some encapsulation was specified). All other type > classes must then be defined on the publicly exported interface. > Yes. If we adopt this view, then type class methods and member functions have a sensible reconciliation. But the question will then arise (in the mind of the developer): when do I use member functions and when do I use type class methods? It becomes a challenge of design, and not one that is easily resolved. My guess is that * most* developers will choose methods, if only because they are familiar... shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
