Ok I have to say that I am not that sure about the immutable thingy as for the regular type. For me an immutable is just like say an Int32 that also does not try to hide that it has 32 bits. Thus I do not see why an ARGB immutable that is bitwise represented by 4 packed bytes should hide its structure. But again, I am not 100% certain about this.
The issues you describe that packages use internals are real but shouldn't be the consequence be to simply fix them when found? Its absolutely normal that packages break when the standard library (base) moves on. I would say this is part of a regular development workflow and not any form of a serious issue. The Julia package landscape is healthy and IMHO in large parts of high quality. Am Dienstag, 7. Juli 2015 15:33:00 UTC+2 schrieb Scott Jones: > > 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 >>> >>
