Function Getters and Setters, what is our consensus?

[Luxxii]

In #2 i saw the following: entry.get_header().get_header(), which uses two getters to retrieve the attributes in a class.

What is our consensus in getters and setters? From my experience, this makes projects less readable and somewhat slow to tangle through. Especially it is tedious to write getters and setters for all attributes or if we want to access attributes in classes within classes (within classes, ...), we chain those getters (as above). Basically, i am wondering what we should decide on:

1. We write getters and setters and also propagate them to other languages (like here in python)
2. We try to avoid them and try to make variables, which should be publicly available, public in structs/classes

Is there a "good practice" or guideline in Rust?

So what are you thoughts!?

(linking @david-bouyssie and @di-hardt , since you two are also mentioned in the PR)

[david-bouyssie]

This double call can be avoided if the code is written in a different way.
I gave some suggestions in my PR review.
You can have a look at it @Luxxii

It's hard to answer your questions because I would say it depends if you speak about the Rust API or the Python API.
On the Python side I would prefer the use of getter/setter most of the time because it can hide internal implementation details.

On the Rust side, I would not use getter/setter systematically and would prefer to have struct with public fields. But not for all cases.

[lazear]

Rust has proper abstract data types, so you can make fields public if necessary. Of course, if you want to encapsulate state/behavior in a struct, then you should keep those fields private and only allow access via methods, etc.

One of the nice features of Rust's type system (and other ML-inspired static type systems) is that you can "make illegal states unrepresentable" [1,2] and enforce program invariants (using the type system to create correct programs & prevent logic bugs). I would recommend that public/API facing types shouldn't be allowed to be directly modified by the user (within reason), so that other parts of the library can assume that the data is valid.

If you are familiar with Rust's standard library (the reference for idiomatic Rust), you will know that very few - if any - structs have public fields - most behavior is encapsulated via methods.

I would also note that exposing data/behavior only via methods has the additional benefit of making it easier to maintain semver compatibility by abstracting away implementation details.

[1] https://blog.janestreet.com/effective-ml-revisited/
[2] https://fsharpforfunandprofit.com/posts/designing-with-types-making-illegal-states-unrepresentable/