On Wed, Jul 8, 2015, at 01:28 PM, Stefan Karpinski wrote: > The real question with any notion of privacy is "private from whom?" > Methods don't belong to any particular argument, so which of their > arguments' private fields are they allowed to fiddle with? And what > about more granular permissions like r/w? There are many ways to > answer these issues, but whatever one chooses, it's more complicated > than just marking some fields as private. It also doesn't enable > anyone to do anything that they couldn't do before, which is what we > tend to prioritize at this point.
This is an excellent point. I'm curious what the exact semantics are of the public/private keywords Scott is proposing. I agree that defining interfaces is currently a problem but there's work on multiple fronts happening to make that better. I think though that the question should not be "How can I restrict what users can do with my package" and more "How do I communicate what I expect users to do". It also seems that between getfield overloading and Traits/Interfaces we'll have mechanisms for package developers to get as granular as they want, and I wouldn't be surprised if someone ends up developing an `@private` macro that automatically overloads field access to raise an error or something. Also FWIW I've always read "Consulting Adults" in a strictly platonic way until the addition of the private parts metaphor. Probably I've actually been reading it more as "Responsible" or "Trustworthy" in the sense that we don't need to go out of our way to protect again bad/stupid behavior in other code. -s
