Hey there,
If you have a generic class that you use as a Process Node that makes itself available as a GlobalChannel, vvvv freezes and crashes.
Repro steps :
- Create a new Class
- Make it generic, enable Process Node
- Add a type parameter
TIn, and a dummy property of type TIn
- Inside this class, on
Create, create a GlobalChannel that has This as a value.
- In your Application, create a Process Node of that class, set some type on the generic input pin
- vvvv freezes and silently crashes
Probably doing something I should not do here :)
Is there any way around that?
See the repro patch : just connect the Float IOBox to the input of MyClassWithTypeParam, and see the crash :-]
ClassTypeParameterGlobalChannelCrash.vl (6.4 KB)
Cheers!
You probably shouldn’t ;)
Of course, vvvv shall not crash when you do something like this. We’ll need to dig into this.
However, let’s pretend it wouldn’t crash for a second. What you are building here seems a bit fishy.
GlobalChannels were meant to be used on a high level to wire stuff together that is somehow concrete. It’s some high-level glue for the end user. Using it in a generic patch seems a bit off since it could encourage us to use this generic patch with different type parameters.
What’s your goal? You might have been interrupted in sketching the complete idea by this crash and indeed wanted to
- create different global channels with different names depending on the type parameter.
- or you might have wanted to have one global channel of type
Object that gets shared by all the different instantiations - independent of the type that they’re using…
Just curious about where you want to go with this.
Edit: In order to make you allow you to test your ideas: This doesn’t crash:
ClassTypeParameterGlobalChannelNoCrash.vl (23.1 KB)
But it feels a bit off. Even for the non-generic case, it feels like a new take on the Singleton pattern, which ideally is already covered by one of the SingleInstance nodes.
GlobalChannels are still new. So maybe some new patterns will arise that we didn’t forsee. Thanks again for documenting the patterns here.
Hey there! Thanks for the elaborated answer!
Got that. I also see it as a very cool feature for library developers. Let’s consider a weather API nuget. I like the idea of it exposing global channels to the end user in an easy to grasp visualization (the Channel Browser) so that one could quickly say ok, this library gives me this, this and that.
Then, accessing such data is as easy as typing its path. In this precise case though, Channel might not make sense because you would want those to be read-only. But still wanna react in an event based fashion when new weather data comes in.
You also run into issues if for whatever reason you duplicate this weather API node : you have channels with duplicate names.
If we put the generic thing apart, yes that’s exactly that. Making stuff available globally without having to connect to anything, but with the advantage that it’s easier to patch, easier to see (Channel Browser), it automagically gives you a named node, and you get the ability to push new values to it for free (if that makes sense).
Of course you could still model that manually with SingleInstance and (Behavior)Subject. Or accessing an instance of a class that has properties of type Channel<T>.
