I don't know, I think all of you have missed my point. I am *not* saying to change anything at all in the behavior of current Julia programs, only ADDING the capability to keep methods, types, or fields which are not intended for public consumption hidden. Being able to do this is very important to make any sorts of guarantees about a program. I've already seen very many cases where things will be broken in the future, because people are accessing internal fields and methods instead of calling exported methods. I had to do a PR specifically to fix a case where JSON.jl was using an internal function of utf16.jl just this week.
Many times, there are methods that are needed to implement some functionality, but which depend on certain things being set up correctly, which you do not want to expose publicly, that are not part of the API, or which you plan on totally changing in the future, for example. The only way to make sure that nobody is using those is to have the language support marking those as private in some fashion, not just some convention that on the whole, doesn't seem to be followed. @tknopp You said that for immutables, that fields were the interface. Please explain that to me, because although Julia conflates a number of different things into the idea of "immutable", I'd never heard that, and don't really see that it could be true. (Julia conflates the abstract idea of something not being settable, with the implementation detail of storing "bitstypes" directly in an "immutable" object, without boxing). I can think easily think of cases where you want a read-only object, where none of the properties were visible (all access via methods). That doesn't change just because Julia can dispatch on multiple arguments, instead of just the (hidden) "self/this" argument. @ninjin (Pontus) You said "Sure, it may break, but ultimately it is always up to the caller not to violate the API" I totally disagree with that. A language should *help* people be able to write correct code. I'm not saying that Julia should be like CLU, where you simply couldn't access the implementation from outside the "cluster" (module), but simply that the level of access should be controllable by the author of the module/package. String handling in julia is a great case for adding the ability to hide the implementation details, and only expose the methods you really want for the API. Currently there are cases of .data throughout base and packages, and the fact that UTF16String and UTF32String currently require a trailing 0 when being constructed is also exposed. Many people have said that Julia's philosophy is one of "consenting adults", but I don't see that at all. To have "consenting adults", you have to have consent on both sides. Julia makes it such that it is impossible to prevent any stranger from walking up and fiddling with your "private parts" (and maybe giving you a virus in the form of corrupted data to boot!). Julian is right about Julia suffering from https://en.wikipedia.org/wiki/Object_orgy although I don't think that member functions are necessary at all to solve this (just a private keyword, that keeps things visible only within the module (and submodules) On Tuesday, July 7, 2015 at 7:15:23 AM UTC-4, Tobias Knopp wrote: > > This is how most Julia code looks like. The methods are the interface and > thus which is exposed in public. > It is pretty natural to program this way when doing generic programming > and taking multiple dispatch into account. > > I agree that this could be better documented somewhere but the solution is > not to bring more complexity into the language. This has also been > discussed several times on the mailing list, so I would be very surprised > that introducing warnings for field access would gain any acceptance among > the core Julia developers. > > > Am Dienstag, 7. Juli 2015 10:54:05 UTC+2 schrieb Pontus Stenetorp: >> >> On 7 July 2015 at 04:12, Ismael VC <[email protected]> wrote: >> > >> > Couldn't we just get a warning and let people shoot themselves in their >> foot >> > if that's what they want? >> > >> > Something like: >> > >> > Warning: Using private method/type in module Foo at foo.jl:n. >> >> I like that you are trying to find some middle ground. But if I am >> doing this intentionally the warning will be a constant annoyance, so, >> how should I silence it? Yet another command line option so that we >> approach gcc/clang with different levels of warnings? Yuck... >> Annotations (@silence?) like Java? Double yuck... >> >> Giving users this level of power is something that I am happy with. >> Last week it allowed me to add temporarily add a function looking deep >> into a composite type from a library when debugging. Sure, it can be >> abused, but it can equally well be used properly when necessary. >> Sure, it may break, but ultimately it is always up to the caller not >> to violate the API. Sure, sometimes base violates this idiom, but >> this is most likely due to historic reasons and a lack of a consensus >> more than anything else. >> >> In the future, given enough experience and evidence to the contrary, I >> would be happy to reconsider my position. But for now, using idioms >> like the one below, is how I write my Julia code. >> >> export Weights, W, b, fanin, fanout >> >> immutable Weights{T<:FloatingPoint} >> W::Matrix{T} >> b::Vector{T} >> end >> Weights(fanin, fanout) = Weights(rand(fanout, fanin)./1024, >> zeros(fanout)) >> W(w) = w.w >> b(w) = w.b >> fanin(w) = size(W(w), 2) >> fanout(w) = size(W(w), 1) >> >> Apologies for the terribly short variable names, it is an example after >> all. >> >> Pontus >> >
