On 23 March 2011 15:21, Ben Kloosterman <[email protected]> wrote: >> >> I feel that member functions for access control is one of the many ways in >> which the concept of 'the object' has been conflated. It is simple, but > it >> doesn't compose, and sometimes it really needs to, where you find yourself >> in a situation where the function needs to be a member (for purposes of >> access) of more than one object. Typically people seem to hack around > such >> things by making more things public or package access. > > But don't type classes w "member methods" specifically allow this case ? > Though we have discussed this may be confusing.
Using multi-parameter typeclass instances as a sort of module concept for delimiting access to the private API? Yes, that sounds like it would compose well, although it is still conceptual abuse :) > I must admit I'm a bit biased since I find member functions ( especially > inline) result in neat code and they don't expose much ( especially if you > also allow private/internal ) resulting in many little but significant > benefits ( simpler auto complete , cleaner namespaces , easier to read/ > understand code , better security etc ) ie Syntactic sugar with > benefits . And they do help from an auditing perspective, too. But I think what shap is interested in here is inferred immutability for performance reasons, which I would argue is a case where programmers should have more control over that inference without having to do a whole stack of copying from the temporary mutable version to the final immutable version, which is occasionally unavoidable if member functions or init-only fields are your only means of restricting mutation. > To me with ignorance it seems well know and simpler than the > other methods suggested and im quite ignorant of region analysis / > uniqueness types ! It can also help simplify deep immutability eg sub > objects passed in or created during the constructor of the parent. I agree that they are a good simple tool, but I don't know if one size really fits all here. > I do find it interesting how the same things seems to interrelate and when > pushed the same things pop out when looked at from different ways ( member > functions , mutability / deep mutability , n > 1 type classes , regions , > constructors and methods vs type classes etc ) .. which means something > and I don't think its entirely my own preoccupations .. Hmm, maybe. Many design discussions tend to the easy way to answer the question "how do I solve X given constraints Y, minimising the degrees of freedom". And that does tend toward simple, at least, simple in the Java sense. "For the compiler to treat paths involving X.y as immutable, y must be an init-only field of class X" has a vaguely Java-Memory-Model ring to it. It grates on the senses, IMAO, because the sense is that the separation of code into functions should be a logical distinction, rather than a semantic one; and the code within a constructor is clearly semantically distinct according to most type systems. This then creates a precedence for further factoring of code, not to suit the programmer's understanding of the system, but to satisfy the constraints of the type system. I would prefer that the type system were flexible enough to match the user, rather than the other way around. I am not going to say that minimising the degrees of freedom is particularly bad, if nothing else, it will yield us a language which does what it says on the tin, provides an environment for safe and reasonably fast systems code. But I can already hear that sigh you might make when you have to drop into SQL for something, and contemplate making another coffee, even though you well know you don't want one. -- William Leslie _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
