fix(ofParameter): better default init() handling of non-comparable/non-copyable objects and containers

[artificiel]

No description provided.

[eduardfrigola]

Hi @artificiel

I found that with this change it stills fails to compile ofParameter<std::vector<ofPath>>.

[ofTheo]

Hi @artificiel

I found that with this change it stills fails to compile ofParameter<std::vector<ofPath>>.

Wow - that's a wild type to try and use. :)
Is there any reason we would want that to compile?

Or is that to illustrate a bigger issue?

[eduardfrigola]

I know is a wild type to use....

The story behind it is that in ofxOceanode, we wanted to make it fast and easy to convert of sketches (apps with minimal code) to oceanode nodes. So you can have modulation, osc control, midi functionality and preset system without much effort.

That meant that ofParameter was chosen as the type for the parameters that could be modulated, but also designed so the output of each node is also an ofParameter, and here is where you can really use any type for ofParameter, and the only interest in here is that in can be put in a ofParameterGroup and you can listen to events when the parameter has changed (and that drives all the logic inside and gui creation).
I'm refactoring this so that creating nodes from ofParameter is an option and not a requirement, and to implement a custom parameter class that suits ofxOceanode needs.

ofParameter<vector<ofPath>> is currently used in some nodes that create vector graphics and need to send its output to other nodes that will process (or render) this paths. See: https://github.com/PlaymodesStudio/ofxOceanodeVectorGraphics/blob/13c87d6ccdbe898eec51a7a25751c618a5d1d128/src/ofxOceanodeVectorGraphics.h#L17-L116

Concerning this pull request, I just wanted to illustrate that still not all types can be compiled due to the addition of init() / reinit() and related to non-comparable/non-copyable objects. Objects that in 0.12.0 where valid ofParameter types and could be compiled.

[ofTheo]

Thanks for the explanation @eduardfrigola !
@artificiel is it easy to make it work as before even with weird types ?

[artificiel]

@eduardfrigola haha indeed a vector as ofParameter is somewhat out there, but it's good to exercice the pattern. I don't mind at all getting odd cases as it augments malleability, and one (personal) goal is to maximize expressivity on the user side, and enabling un-planned use is a good measure of such expressivity. again this init() stuff is new anyway so it's the right time to figure out things. so please test the current PR again before it gets merged, and throw other funny things at it if you have them.

(also, I dived into ofParameter/ofEvent in an attempt to squeeze more expressivity in the type, but discovered some limits inherent to the design, which is actually a coupled cluster (ofxGui etc.). the behaviour you need (a observable container of heterogeneous classes, including itself) is supported by ofParameterGroup, but it should probably be extracted into a more generic Tree-type class, but the class hierarchy makes it hard. I have different experiments that have clearer designs (including a much cleaner ofParameter.h, which is a hairy file in itself, and difficult to split), but nothing that can slide under the current designed unnoticed, not because of "user parameter" considerations but how it ties into ofEvents). there is room for a non-OFsystem-intertwined parameter-value type).

anyhow the problem was the trait checked for the existence of operator== but not if it would actually compile wit given type <T>. as of now you cannot compare ofPaths, but you can compare vectors. however if you try to compare vectors of paths compilation will not work (which is expected — I don't see any efficient way of comparing ofPath). so now the template digs a little deeper; not really complicated and actually more correct.

i also found a small return value bug, and this closes #8332 too, by prioritizing actual value assignment over silently creating an ofParameter wrapper that gets immediately thrown away.

[eduardfrigola]

Thanks @artificiel!
Now seems to fix all the issues in my use case!

[ofTheo]

Thanks @artificiel @eduardfrigola !!

[eduardfrigola]

Thanks everyone! Closing resolved issues by this.