I’d avoid using the phrase “consenting adults” with regards to Julia’s philosophy, for two reasons (and this was discussed back a year and a half ago)
- Outside of some discussions of Python, it is almost exclusively used in a sexual context (every dictionary definition I’ve found as been along the lines of:
a person who is considered old enough, and therefore responsible enough, to decide if they want sex and who they want to have sex with
Since people take great pains to avoid even references to gender (unavoidable in many languages) with respect to Julia, this seems to be very inappropriate.
- If there is no means of denying consent (i.e. by having the means to make something private, or to mark something as public [even if it is not exported because you don’t want to pollute the namespace] even if it just causes a warning if you access something private, like a deprecation, and/or requires some special “sin-tax” (like
..instead of., as CL does with :: instead of:), then you can’t really claim there is consent (just as in the US at least, being married doesn’t imply a blanket consent)
Most of the time, I think that types/fields of types/constants within a module are considered private (which is why having to use _ in front of all of them a la Python to indicate that would be a big pain), but also many times, modules or packages don’t necessarily want to export everything that they mean to be part of a public API, because that would cause a lot of namespace pollution (Pkg and PkgDev are examples).
My proposal would be to add a “public” keyword, like “export”.
Names not exported or public would still be accessible outside the module via new syntax (.. seems to be the prefered syntax that I’ve seen).
‘using’ would bring into the current namespace all the exported names, all public names would be available via normal . syntax, and all others would be available via ... Trying to access a name not exported or public via . could simply give a warning like deprecation does (so that people 1) know that the name/field is not part of the public API 2) they can push to get something added to the public API if they need to 3) they can pay the “sin tax” of adding the extra . to avoid the warning - which means those places can easily be found if things later break [like accesses to .data now with jb/fasterstring]
import would act the same, except would not bring anything into the current namespace.
This would make it very clear exactly what is intended to be available via the public API (even if not exported), something this is not the case currently.
I think this approach would be enough for those of us who need to manage large projects in Julia with many developers, without really slowing down people who just want to get something done in Julia.
In other words, I do think we can have our cake and eat it too.