Having a wildly adopted naming convention or description in documentation is great, but a syntax for it would even be better in my opinion. Access to private properties from outside should not be technically forbidden because this would make testing more difficult (and prevent hacks which are sometimes handy), but the “private/ public” information could be e.g. used in the linter.
For example I really like the ! convention for mutating functions. But a strict syntax for it, indicating which argument is (potentially) modified, would make it even more powerful. For example this would solve the issue that Pluto cannot detect variable mutations for building the dependency tree.
2 Likes
It makes code more messy, I like the consistency of the function call interface. When I see dot access, I always wonder if the code is fiddling around with internals. The same issue occurs with packages that export part of their public API, so that some, but not all, function calls require the package name prefix. It looks hacky.
I like the philosophy of organizing functionality around functions instead of around data.
It looks more like class-based OOP.
It changes the general culture, for example, changing internal names is suddenly a bigger deal, and is likely to break more code.
It works poorly with broadcasting.
It looks more like class-based OOP.
4 Likes
I don’t like the idea that I would need to change the name of some property to indicate it is public. TBH I believe propertynames and getproperty are already good indicators of what is public and what is private, what is needed is that people use these indicators in their code more often, and also make changes explicit in documentation (just like you do when you change a function name, arguments, etc).
3 Likes
I agree, I don’t think there should be a naming convention for public attributes.
The problem with the current implementation of propertynames is that it returns all the properties by default. I think if there needs to be a function like that, it should be called internalpropertynames or allpropertynames, and propertynames should return an empty collection by default, because properties should be private by default. This could be overridden by authors who want to provide particular public properties.
3 Likes
I understand.
Perhaps the best should be able to export properties from a module. Then, if you want to use internal properties from another module, you would need to explicitly import them. Or using double dots object..private_property.
1 Like
By the way, .. is a valid identifier in Julia and parses as an infix function. I wonder how an experimental package could provide that functionality. Unfortunately, Julia lowers a.b to Base.getproperty(a, :b). It would be easy if that syntax was lowered to get_property_for_module(__module__, a, :b) or something like that.
Edit: Nevermind, the parser for .. would have to be changed too.
Properties are symbols, and in Julia (as opposed to eg Common Lisp) they share a single namespace. This can also be considered a convenience, making getproperty accessors ideal for lightweight, user-facing interfaces where no explicit namespace management is necessary.
For situations where explicit namespace management and hiding internals is desirable, I would recommend explicit accessor functions. They should have zero runtime cost, and make refactoring and deprecation much easier.