In the day I’ve been away, it seems the discussion has taken a different turn. That’s fine, but I want to state my position clearly:
While sympathising with @ScottPJones’s concerns, my issue is not with modules/namespaces: they constitute a permissive structure which might get a bit clunky for the rollercoasting world of Julia if privacy were introduced.
I am never for lint solutions. While not necessarily laying down rules for responsible adult behaviour, a computer language should define what the term ‘responsible adult’ means. Sane laws do not permit children to walk around carrying guns, but instead provide them with a social context in which that isn’t necessary. IMO Julia needs to provide a clear definition of forms of behaviour which are known to be dangerous and provide a minimal opportunity for programmers to prohibit that behaviour.
Tampering with certain data fields in a type can be (a) dangerous and (b) non-obvious. I teach programming to students and they do not always document their programs to indicate that this field fulfills a constraint which must not be violated. Julia should provide a simple, minimal way for the programmer to do this, which if later removed will not bring all clients crashing to the ground. The solution must therefore be prohibitive, rather than permissive.
In my opinion, a simple, minimally prohibitive way of doing this is to allow the keyword ‘private’ to label sections of type-datafieldsonly (so no functions or constructors) as being visible only to the next enclosing scope. This would give all multiply dispatched functions in the enclosing module the opportunity to have their wicked way with the private fields, and if the word ‘private’ were later removed, no-one would get burned.
I’m sorry, I don’t understand the question. Do you mean “How would I implement the compiler feature?”, or “How would I denote privacy in my code?”? In the first case, I really couldn’t say, not having looked at the compiler code - I can’t imagine it would be difficult. In the second case, I’m simply thinking of something like this:
module Wallets
type Wallet
colour::Colour;
zipFastener::Bool;
private:
contents::Float64;
maxCapacity::Float64;
end
end
(Sorry: I couldn’t work out how to enter tabs in this editor)
I know it’s an old thread but I hope I can add a bit of value by throwing 2 extra cents - especially as I’m happy to see that this has been tagged for v2.0 (hopefully will make it through!). Although technically my interest is in private struct fields.
I stumbled onto this as part of my research into some presentation about data structures in Julia - thinking how to memoize the length of a linked list so that length(l::LinkedList) would run at O(1) instead of O(n). Obviously, by having a length field which is kept in sync with the actual number of nodes. But I was wondering how to keep that private so it can’t be tampered with. I thought a good idea would be to peek into Julia’s Dict type and see how it’s done there. Unfortunately, that didn’t help as one can just change the count field messing it all up:
My point is: most replies assume that code will always run in a fully controlled environment and that conventions will be followed. However, if due to some bug (bad stuff sometimes happens!) an attacker would be able to change the internal state of such a Dict and there would be logic depending on length(d::Dict), it would be a nightmare to debug.
Considerate developers do not use undocumented APIs and I doubt many Julia developers are aware of the internals of a Dict (or other data structures) so the thought of checking the internal state would probably never occur. Because we try to abide by some informal principles of encapsulation doesn’t mean others will too - the more the language can protect us, the better.
P.S. Loving PrivateRyan.jl btw, too bad it hasn’t been kept up to date.