Subscription conflicts due to statics in generic class about pushqa

[PeteGoo]

Thanks for the feedback.

In regards to static state on generic types see this gist I just created https://gist.github.com/PeteGoo/5043985
also this http://stackoverflow.com/questions/9647641/resharper-warns-static-field-in-generic-type

Totally agree on the cleanup of the subscriptions. I'll have a look at a fix soon.

[IanYates]

The gist looks like it confirms Jon Skeet's answer on StackOverflow, which disagrees with

[According to ReSharper...] Static objects in generic classes are shared regardless of the type of T.

There's a bit on the gist which threw me for a moment when I adapted it for Linqpad - You had

Console.WriteLine("setting a = b1");
Foo.SharedValue = "a2";

The WriteLine should be "setting a = a2" :)

I'm looking at possibly making use of this project in some upcoming development so I have the follow tag set - sorry to bust in on the issue discussion...

[PeteGoo]

bust away! Welcome. The intention was to take advantage of the inherent per-type combination caching that comes as part of putting a static field on a generic.

Whoops, yes, updated the gist

[scottt732]

Yeah.. You're right. I noticed the warning yesterday when I switched from the package reference to the library reference to debug through some stuff. I was having a hell of a time debugging a bug where I was getting 1-3 of the events on an infinite Qbservable stream and naturally assumed it was your fault :-). I was using a ReplaySubject with an AsQbservable and I needed to make them both static. I was getting new instances of the context and didn't realize it. That and I misinterpreted the Resharper warning backwardslywise.

So if the type collection really is specific to T's, nevermind that part. I'm still trying to wrap my head all the way around Rx, but I think this IDisposable disposal thing might still be relevant.

This project is a game changer... It was pretty trivial to give a simple log4net appender splunk-like super powers.