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. "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. Sandro _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
