-
Notifications
You must be signed in to change notification settings - Fork 51
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
Apply new frontend design to Container and deriving classes #1115
Conversation
d0396be
to
4747b28
Compare
I have now also simplified the whole design again a bit. First approach: Split
While this works alright, it's quite a lot of classes.
This is now quite close to the old implementation again, with one key difference: All stateful data held by the The class Series nonOwningInternalSeries{ std::shared_ptr< internal::SeriesData >{ &seriesData, []( auto const * ){} } }; One downside of this is that for class hierarchies, you now have one redundant |
8e5e205
to
ce67036
Compare
@eschnett Hi Erik, How should we go forward on this? Would it be ok for you to check how much this breaks the Julia bindings? In which order would you prefer your and this PR to be applied? There's no hurry as I'm in vacation next week. (Also, some time after your PR is merged, we generally should synchronize on how to maintain the bindings) |
@franzpoeschel I think the ball is currently in my court to add CI tests for the Julia bindings. Before that it'd be difficult for you to maintain the Julia bindings, or to update them when necessary. Given this, I'd say: go ahead and merge the changes. The branch with the Julia bindings will continue to work (since it doesn't have the new changes), and I'll merge the changes and update the Yggdrasil build in one go. This way there won't be any breakage seen from Julia. I'd love to have a preview on your changes, but realistically not in the next week, so don't let me slow you down. |
Ok, then we'll go forward with this first :) If you need any help merging, just ask |
Users can now choose whether to copy the container or not Necessary if working on internal (non-copiable) classes
Same goes for deriving classes, except those that have no own data.
ce67036
to
e23792a
Compare
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 really good to me. Thanks a lot for this!
Just one comment about the implementation of the get()
ers and one follow-up idea about catching up documenting the m_
members in ...Data
classes.
return const_cast< internal::BaseRecordComponentData & >( | ||
static_cast< BaseRecordComponent const * >( this )->get() ); |
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.
For these getters, wouldn't return *m_baseRecordComponentData;
work here as well and be more legible? :)
I think duplicating the single line does no harm as they are close by and is more readable then the current construct.
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.
Yeah .. maybe you're right about this :D
bit of tunnel vision on my side there
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.
No worries, feel free to fix in a separate follow-up.
RecordComponentData & operator=( RecordComponentData const & ) = delete; | ||
RecordComponentData & operator=( RecordComponentData && ) = delete; | ||
|
||
std::queue< IOTask > m_chunks; |
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.
For all the ...Data
classes, it would be really good if we try to catch up and add Doxygen strings to the m_
member variables.
Can be a follow-up and we can split the work if we are unsure about some. I remember we found them hard to follow at times and it's good to document the purpose of individual m_
member variables.
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.
Note: Inside #1154 I began aliasing these data classes (needed that for something else in there) which made the whole thing a lot more readable in my opinion, e.g.:
namespace internal {
class RecordComponentData{ /* … */ };
}
class RecordComponent {
using DataClass = internal::RecordComponentData;
std::shared_ptr< DataClass > m_recordComponentData;
/* … */
};
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.
That is very nice, yes 💖
But my comment was actually about adding doxygen to the members in the data class, so we know what they are for:
struct RecordComponentData
{
// ...
//! container for holding data chunks
std::queue< IOTask > m_chunks;
//! this sets things on fire
bool m_fire;
};
I recall that all the original m_dirty
and m_flushed
members among others were often hard to understand for us without searching through their usage.
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.
Ah, got you
Yep, these classes are probably a good chance to have documentation for our internal state at one central place
Starting CI again because we haven't pushed to the branch in a bit (to see if merge is still green). |
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.
If CI passes then I'll merge this already, since my comments can all be addressed in follow-ups.
Follow-up to #886.
This splits
Container
and deriving classes into a data and an interface class.TODO:
Container
,BaseRecord
,RecordComponent
,BaseRecordComponent
,PatchRecordComponent
,Iteration
PatchRecord
,ParticlePatches
,ParticleSpecies
(its only memberParticlePatches
already has handle semantics),Mesh
This PR prepares for a necessary UX frontend redesign that will be a follow-up:
SCALAR
trick for instantiating datasets that have no x,y,z components is confusing for users, I've had to explain this several times now and it doesn't really make sense. Make it so that instead ofauto E_x = series.iterations[0].meshes["temperature"][SCALAR]
one can equivalently writeauto E_x = series.iterations[0].meshes["temperature"]
.To do this, probably do something like:
Record
for that as it has a similar purposeRecordComponent
)