Skip to content
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 proposal for protected attribute in derived types #31

Merged
merged 2 commits into from
Feb 21, 2020

Conversation

aradi
Copy link
Contributor

@aradi aradi commented Oct 21, 2019

No description provided.

@certik
Copy link
Member

certik commented Oct 21, 2019

@aradi, thanks for submitting this. I have a few questions. Wouldn't your example work with current Fortran already? I would like to see an example which does not work with current Fortran, and shows how the "protected" attribute improves things.

@certik
Copy link
Member

certik commented Oct 21, 2019

Ah I see --- it's something like const in C++? It makes the attribute constant / read only. I thought this was about making the member "private".

@aradi
Copy link
Contributor Author

aradi commented Oct 21, 2019

I added some more explanation. The case presented would be only possible, if the component were made public, but that would jeopardize data consistency.

@aradi
Copy link
Contributor Author

aradi commented Oct 21, 2019

Yes, it was meant like const in C++ (and not as protected in C++ 😉 )

@zbeekman
Copy link

zbeekman commented Nov 8, 2019

I've wanted this for a long time. Writing a ton of getter methods is a pain in the ass and a waste of time. An attribute that would only allow modification by TBPs would be really nice, and would allow for direct reading of UDT components.

@certik
Copy link
Member

certik commented Nov 8, 2019

@aradi I did not forget about this PR --- I first want to figure out a workflow with the committee how to consider proposals such as this one. Things will start moving in the next few weeks.

@aradi
Copy link
Contributor Author

aradi commented Nov 11, 2019

All fine, thanks in advance and especially thanks for all your efforts into involving the community!

@certik
Copy link
Member

certik commented Jan 3, 2020

@aradi, can you comment on #122 and (hopefully) list it among your top 5? We'll now start drafting proposals, so we'll figure out some good template and help you finish it, and you can help us with other proposals also.

Copy link
Member

@zjibben zjibben left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is something I frequently wish we had in Fortran. I'd like to submit this proposal for the meeting next week, and I think it's in pretty good shape. There hasn't been much discussion--is there anything we should iron out first?

@aradi
Copy link
Contributor Author

aradi commented Feb 21, 2020

@zjibben Thanks! I think, the proposal is trivial enough not to have side effects or unwanted implications, this is why there was not much discussion about it.

@jvdp1
Copy link
Contributor

jvdp1 commented Feb 21, 2020

Thanks for this proposal. It is something I tried intuitively once (without success of course ;) ), before reading one more time the documentation of protected.

@certik
Copy link
Member

certik commented Feb 21, 2020

I assigned to @zjibben to merge when he thinks it's ready.

@zjibben zjibben merged commit 771f01a into j3-fortran:master Feb 21, 2020
@zjibben
Copy link
Member

zjibben commented Feb 21, 2020

I went ahead and merged. I agree, I think this is straightforward enough to not need more clarification, but if anyone thinks of something please leave a comment or submit a PR! I’ll submit this weekend otherwise. Thanks for the proposal @aradi !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants