I would like to understand Julia’s rationale for not including a language-level privacy feature: a way to truly protect the internal state from outside access. I’m aware that we can use closures to emulate encapsulation, but that’s cumbersome, and it’s not really the same as a built-in mechanism. I…

I found this weird, too, at the beginning. Now I believe: the Julia status quo is preferable to what the stricter, “object-oriented”, languages have the status quo will improve further The benefits exist for interactive usage, e.g., in exploration in the REPL, also testing, in some cases. This is…

It’s not only structs, but also functions/methods. Nothing prevents you from making e.g. Int an iterator to iterate through the numbers below (if one believes in the von Neumann definition of the natural numbers): function Base.iterate(n::Int, state=nothing) isnothing(state) && return n<=0 ? no…

This feature and a way to describe an API and force it on the implementation is the two language features I miss the most. Edit: I am not considering small binaries / AOT / creation of libraries a language feature :smiley:

[image] younes: I’m aware that we can use closures to emulate encapsulation, Hopefully you are aware that closures provide only marginally more privacy than structs, e.g.: julia> f(a) = () -> a f (generic function with 1 method) julia> b = f([55,77]) #3 (generic function with 1 method) jul…

[image] younes: direct messing with internal structs can still lead to logical or invariant-breaking bugs It also lets you extend behavior without waiting for the public API to allow it, and it’s often not a reasonable expectation for the public API to irreversibly support something that you …

There’s propertynames for marking a property as public. It defaults to making all fields be public properties, sadly.

Good catch, I think you’re refering to propertynames though. Does that mean hasproperty can be used for validation like ispublic?

I don’t think you can “truly” protect internal state from outside access in a compiled language. You can always convert to a Ptr and access/modify data manually. So privacy is a question of programming convenience, not of actual safety. So with that in mind: the benefits of a strict enforcement at …

[image] dlfivefifty: This does make my packages somewhat brittle I am having trouble right now with wrapping a C++ library where too much of attributes are made private. As you have said, it’s possible to circumvent that by taking raw pointers etc. and it would be much more brittle than in Ju…

[image] Benny: Does that mean hasproperty can be used for validation like ispublic? Not in practice, at least not in general. All fields are declared as public properties by default, and it’s actually kinda rare to define a propertynamesmethod for one’s type, so hasproperty will usually answe…

Why doesn’t Julia offer built-in privacy/encapsulation features?

General Usage

stevengj January 11, 2025, 5:10pm 10

@StefanKarpinski’s post in a related thread may give some insight into the underlying philosophy: Private states in Julia modules - #19 by StefanKarpinski

Topic		Replies	Views
Private states in Julia modules General Usage question , package	24	7858	November 20, 2024
Mutable struct vs closure New to Julia struct , closure	74	5920	February 1, 2019
Base.modules_warned_for silently removed in 1.8 General Usage breaking	133	5119	June 16, 2022
Implementation Hiding Proposal Internals & Design proposal	19	1794	May 10, 2018
Accessing type internal fields in package interfaces General Usage question	14	1703	October 28, 2021

Why doesn’t Julia offer built-in privacy/encapsulation features?

Related topics