Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dependency of Rx #34

Closed
pnowosie opened this issue Oct 5, 2015 · 1 comment
Closed

Dependency of Rx #34

pnowosie opened this issue Oct 5, 2015 · 1 comment

Comments

@pnowosie
Copy link

pnowosie commented Oct 5, 2015

Since version 1.5.0 Language-Ext is depended on 5 Rx packages, which makes me confused as I really need just Option, Either and tuples and list helpers.
I wonder if it will be an effort to minimize dependencies of the Lang-Ext.Core?

@louthy
Copy link
Owner

louthy commented Oct 5, 2015

The Core relies on Rx-Main, which brings in the other 4. I have reduced that to only needing Rx-Core (which also brings in Rx-Interfaces) and RxLinq. This reduces the dependency requirement.

Rx is a definitely a large part of the functional story in .NET; I want LangExt to be part of that story and not ignore it. There are functions in Option that use it (MatchObservable for example) and some other support functions like delay for scheduling execution of a Func<T>. The number of 'Observable aware' functions will grow.

And whilst I could split some of the functions out into a LanguageExt.Core.Rx dll; not all can. The value of the Prelude partial class is that you can write using static LanguageExt.Prelude once and then you get the functional world in C#. Unfortunately partial classes can't span multiple assemblies, and therefore I'd have to split the Prelude which I'd rather not do.

LangExt did previously depend on System.Collections.Immutable and a WeakConcurrency project which it now doesn't. So hopefully the overhead isn't too bad.

@louthy louthy closed this as completed Oct 14, 2015
StefanBertels pushed a commit to StefanBertels/language-ext that referenced this issue Aug 13, 2018
More robust error handling for redis exceptions
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants