-
Notifications
You must be signed in to change notification settings - Fork 4
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
Functions that allow easy creation of new but related structs #90
Comments
@SamuelBrand1 thoughts? |
This is handy functionality. Maybe, have Atm, its easy to swap in a new discrete GI; but that would let us swap in a new continuous GI as well. |
Basically, I'm thinking The methods for And the |
In fact, can I request that we call it |
So yes the idea was to make one for all the structs and the We need to define a method for every struct we use right? |
That might be easiest, but in the as an example maybe aim for this pseudocode function remake(my_struct::AbstractModel; kwargs_to_change...)
ty = typeof(my_struct)
ty_all_kw_args = fieldnames(ty)
nm_tuple_not_changing = get_values_for_kw_not_changing(my_struct, ty_all_kw_args, kwargs_to_change)
all_kws = merge(kwargs_to_change, nm_tuple_not_changing)
#Use constructor
ty(all_kws)
end |
Actually, we could just lift this with reference to SciML. We'd just need this and their most general Its an elegant way of doing the
pseduocode above. |
Here should we be lifting or should we be depending on them (just for these things?) |
More generally we don't have any namespace management of the functions we use (just the packages) like we would in R. Is that because we don't need to (and so this represents best practice) or is this really something we should have but don't? |
I think |
In all the Julia I've seen namespace management is just up to modules and package exports and python-like patterns like import EpiAware as epa
epa.my_epi_aware_func(args...) I imagine its heading towards things like this, because it has the same potential namespace issues as python can have? |
ah okay so its not that it just magically works but rather that its a rough edge |
Yeah I was really asking if there was a clever way to just dep on the parts of their package that you wanted but it sounds like no. |
A final org queston. When we define function generics (like Looking at docs practice its definitely best practice to document functions all together |
The current plan is to import sciml base for this functionality and see how that works |
Internally, you can use e.g. using SciMLBase: remake But I'm not sure how much that lightens the dep vs namespace management (which is also useful). |
I think that will just help with namespace management but is worth doing anyway for clarity I think |
Personally, I've come round to just use it. |
This functionality also seems to be supported by |
Yes I think having |
@seabbs I think we've gone for |
I think we need to document that option somewhere clear and then can close (perhaps the proposed FAQ) |
Closing in favour of #276 |
For many of our use cases it would be great to be able to create new structs for some/all of our structs with just a single input change.
It looks like the suggested approach to do this is to create a function that dispatches on the struct and creates a new struct.
I've created a test of this in
issue90
Questions
The text was updated successfully, but these errors were encountered: