In-depth analysis indicated that an ''opaque solution'' would be possible,
yet complex to implement in detail
- a Builder interface would be required
- this interface needs to package all given param values as ValBuff
- furthermore, each such value must be accompanied with a BaseTypeID
- the actual builder would then become ''a PImpl''
- it could be either implemented as heap-allocated with unique_ptr
- or be a `PolymorphicValue` itself (in which case the builder front-end
should be non-copyable and used by reference, inline in a builder expression
- in any case, the front-End builder would proxy all calls to the actual builder
- and the latter would return an opaque parameter at the end
This setup would even allow to use ''full type erasure'' on the Parameter front-end,
and might reduce the ''header inclusion tax''
BUT -- that being said, if we just require the user to specify the desired type explicitly,
not only when building a new parameter, but also when cloning a parameter from a prototype,
then the actual implementation could use one simple builder object and all the complexities
outlined above could be skipped.
So the latter is what we do for now -- since this whole effort is rather a
design draft and should enable to explore actual usages of the parameter framework.
At a later point, the elaborate version could still be implemented
Ichthyostega
af3d8f5b58