# Regarding \`getproperty\` and public vs. private APIs

**URL:** <https://discourse.julialang.org/t/regarding-getproperty-and-public-vs-private-apis/63059>\
**Category:** Internals & Design\
**Tags:** question\
**Created:** [June 16, 2021, 4:25am UTC](https://discourse.julialang.org/t/regarding-getproperty-and-public-vs-private-apis/63059 "2021-06-16T04:25:35Z")\
**Posts on this page:** 7\
**Page:** 2

<div class="post-metadata">

**Author:** ![lungben](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lungben/32/12314_2.png) [@lungben](https://discourse.julialang.org/u/lungben)\
**Post date:** [June 17, 2021, 7:33am UTC](https://discourse.julialang.org/t/regarding-getproperty-and-public-vs-private-apis/63059/21 "2021-06-17T07:33:25Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [June 17, 2021, 7:51am UTC](https://discourse.julialang.org/t/regarding-getproperty-and-public-vs-private-apis/63059/22 "2021-06-17T07:51:42Z")

</div>

> [@jzr](#):
>
> Could you elaborate on why you don’t like it?

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.

---

<div class="post-metadata">

**Author:** ![jessymilare](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jessymilare/32/13750_2.png) [@jessymilare](https://discourse.julialang.org/u/jessymilare)\
**Post date:** [June 17, 2021, 8:13pm UTC](https://discourse.julialang.org/t/regarding-getproperty-and-public-vs-private-apis/63059/23 "2021-06-17T20:13:32Z")

</div>

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).

---

<div class="post-metadata">

**Author:** ![jzr](https://avatars.discourse-cdn.com/v4/letter/j/eb9ed0/32.png) [@jzr](https://discourse.julialang.org/u/jzr)\
**Post date:** [June 17, 2021, 8:35pm UTC](https://discourse.julialang.org/t/regarding-getproperty-and-public-vs-private-apis/63059/24 "2021-06-17T20:35:29Z")

</div>

> [@jessymilare](#):
>
> I don’t like the idea that I would need to change the name of some property to indicate it is public.

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.

---

<div class="post-metadata">

**Author:** ![jessymilare](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jessymilare/32/13750_2.png) [@jessymilare](https://discourse.julialang.org/u/jessymilare)\
**Post date:** [June 17, 2021, 8:46pm UTC](https://discourse.julialang.org/t/regarding-getproperty-and-public-vs-private-apis/63059/25 "2021-06-17T20:46:44Z")

</div>

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`.

---

<div class="post-metadata">

**Author:** ![jessymilare](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jessymilare/32/13750_2.png) [@jessymilare](https://discourse.julialang.org/u/jessymilare)\
**Post date:** [June 17, 2021, 9:23pm UTC](https://discourse.julialang.org/t/regarding-getproperty-and-public-vs-private-apis/63059/26 "2021-06-17T21:23:28Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [July 15, 2021, 8:14am UTC](https://discourse.julialang.org/t/regarding-getproperty-and-public-vs-private-apis/63059/27 "2021-07-15T08:14:48Z")

</div>

> [@jessymilare](#):
>
> Perhaps the best should be able to export properties from a module.

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.

[Previous page](https://discourse.julialang.org/t/regarding-getproperty-and-public-vs-private-apis/63059.md?page=1)