-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add developer documentation and design principles #72
base: master
Are you sure you want to change the base?
Conversation
New section "Developer Documentation" is aimed at developers wanting to work on PICMI itself. Its content may be of interest to implementors, but should not be required knowledge to them. The design principles outlines fundamental design decisions and aims to clarify misunderstandings on PICMI at an early stage.
Note: I am not that familiar with the rst format, feel free to make suggestions. |
I've proofread and would put considers this document "done", at least for the basics. I summon @dpgrote @ax3l @BrianMarre for their opinions! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no problem with that point. The only thing we should note is that writing attributes directly can invoke undefined behavior (inconsistent objects if not all corresponding members are updated). Reading is actually no issue, unless we want to hide unit conversions within. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me.
@s9105947 @BrianMarre just a minor question to clarify above, if you have a chance :) |
Yes it probably is a good idea to note that writing to attributes causes undefined behaviour, and yes I agree that reading should not cause problems, as in both will probably not cause and should under no circumstances cause problems by design. Edit: I did change my mind somewhat, we should discourage the user from needlessly reading variables but it should not be disallowed in general |
|
||
Note that even if not recommended direct access to member variables | ||
of objects is still possible. | ||
Accessing the member variables directly (both reading and writing) results in **undefined behavior**. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that not encouraging read access, is justified, since read-to-set-other-variable creates a lot of implicit dependencies difficult to oversee
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agreed, we can recommend using getters instead
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@BrianMarre @s9105947 want to update accordingly? :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but I am on vacation right now and Hannes moved on.
I am actually not sure wether I even have write access to this pull request.
Might be that we have to get a developer to push to this pull request or, create a new one.
New section "Developer Documentation" is aimed at developers wanting to
work on PICMI itself. Its content may be of interest to implementors,
but should not be required knowledge to them.
The design principles outlines fundamental design decisions and aims to
clarify misunderstandings on PICMI at an early stage.
Key points that are important to me personally: