Should unflatten unwrap Fixed values?

[jonniedie]

I am finally getting around to #30. In doing so I noticed:

julia> x = (1, 2.0, fixed(3.0))
(1, 2.0, ParameterHandling.Fixed{Float64}(3.0))

julia> v, unflatten = flatten(x);

julia> unflatten(v)
(1, 2.0, ParameterHandling.Fixed{Float64}(3.0))

Since wrapping something in Fixed is only done for the sake of the flatten/unflatten machinery, I wonder if it would be better for unflatten to return the unwrapped value of the Fixed number, since that's all end users will generally care about. Or I guess another question to ask is: Are there any situations where the end user would want the Fixed-wrapped value rather than just the value itself?

[willtebbutt]

Are there any situations where the end user would want the Fixed-wrapped value rather than just the value itself?

Probably not, but our current semantics for unflatten are "give me back the thing I flattened". The expectation is that the user will call ParameterHandling.value on a thing with parameters in to strip out the parameter types, and just give the underlying values.

edit: so it's standard practice (as far as anything can be called standard in an early-stage package like this) to define a helper function

unpack = ParameterHandling.value ∘ unflatten

that does what you're after.

[jonniedie]

That makes sense. I partially ask because I want to make sure Tagged behaves the same way the other wrapper types in ParameterHandling do. Maybe it would be worth exporting a "flatten in such a way that it will unflatten to just the values I want" function like (although preferably with a better name than value_flatten):

function value_flatten(args...)
    v, unflatten = flatten(args...)
    return v, value ∘ unflatten
end

to save users the extra step? Or is this the wrong level to handle this at?

[willtebbutt]

No, that's an excellent idea (I wish I had thought to do this months ago). Would definitely be interested in a PR which adds that.