I've seen what happens both in the internal code of a language, and the customer usage, over 3 decades, and know first-hand the issues that come up when you don't have the *option* of making things private. (having the distinction between "public" and "private" in the language was something we had to add after years of problems)
Nothing about my proposal would *force* you to use it, it would not break *any* current julia code. Also, I don't think it is at all good that people consider it "normal" that things break constantly, esp. when there are simple ways that a lot of the pain could be avoided. On Tuesday, July 7, 2015 at 10:11:46 AM UTC-4, Tobias Knopp wrote: > > 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 >>>> >>>
