On Wednesday, July 8, 2015 at 2:30:40 PM UTC-4, Spencer Russell wrote: > > 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. >
Encapsulation gives the implementor of something a lot more freedom, to improve things as time goes on, without worrying that somebody is depending on some internal part of the implemention, rather than the abstraction. That to me is enabling something that can't be done currently. It's something that in the short time I've been dealing with Julia, I've already been bitten by. My idea of @public/@private (or whatever) is that public things, even if not exported, are OK to be used outside the module (i.e. as module.name). That is good for things where you don't really want to pollute the enclosing namespace, and they are useful functions (or types, etc.). Frequently utility functions for a type might fall into that category. I'd probably say that unexported names are by default private (but then, I'd make warnings/errors from the compiler based on a switch like deprecations use, i.e. Base.JLOptions.depwarn, which is 0 for no warnings, 1 for a single warning, 2 for getting an error.) Since most people seem to like the everything visible model (at least while developing), that could be set to 0 by default. You might also be able to make a type public, but then make certain fields private. (you can't really do the opposite, because if the type is private, you won't see the fields anyway). public and private to me, would just be at the module level. If it is visible in the module, it would also be visible to all submodules. 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. > > That surprises me, I've never heard that phrase used in any other way than the legal definition, or the way any dictionary I've ever seen defines it, which I won't quote here so as not to annoy people bothered by it. (I think it's hard to square the frequency with which the phrase "consenting adults" has been thrown around for years in the julia community, given the definition of the phrase, with the "julia community standards" which I was pointed to, when I made the mistake of using the female pronoun for julia one time [you talk about boats using the female pronoun in English, and that's not "sexualizing" the boat, is it? "Genderizing", maybe]) > -s >
