-
Notifications
You must be signed in to change notification settings - Fork 11
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
default behavior for flatten/unflatten with any type #75
Comments
Hi @FerreolS . Thanks for opening this. I think you should probably consider using We don't provide the kind of default method that you suggest precisely because we want users to actively make decisions about how their types ought to be treated, rather than run the risk of silently doing the wrong thing. |
Thanks @willtebbutt for you prompt answer. Probably |
Ahh I see. Unfortunately I'm not sure that ParameterHandling.jl is really the tool for this kind of thing. It's intended use is largely not that you would build an arbitrary type, and then be able to flatten / unflatten it. Rather, it is intended to provide a convenient way to assemble simple data structures comprising tuples / named tuples / arrays etc, which are easy to then convert into your desired type. For example, see the intended style here -- the parameters live in a named tuple, and we have a function ( |
Hi,
I'm using
ParameterHandling
only for the flatten/unflatten tools. In my case I need to carry extra information within my tuple stored in different type that do not need to be flatten but I need to recover it in my restructured NamedTupleHere is an example
If I try to flatten this tuple I get an error:
However, with this simple overloading of
ParameterHandling.flatten
as a default behaviourI get:
Is there any reason for not implementing such default behavior? Am I missing something?
Should I make a PR?
The text was updated successfully, but these errors were encountered: