This project is read-only.

Support for .NET 4.0 Expression Trees

Nov 23, 2009 at 3:16 PM

Hi there,

You've done some fantastic work with this library--I've had a lot of fun experimenting with it.  I was wondering if you have plans to support some the new expression types in .NET 4.0 (the extended expression trees created for the DLR).  While many of the new expression types can't be effectively observed, I'm sure some of them can.



Nov 25, 2009 at 1:27 PM

Hi Mike,

It is good to hear that you are enjoying it! I haven't had a chance yet to take an in depth look at the new 4.0 expression trees. With the scanty looks that I did take i'm afraid that the new additions make the expressions quite a bit more complex.

C# 4.0 itself will open up a whole new avenue of possibilities with contra- and covariance functionality.  

Right now I'm trying to make error handling a bit more robust. It is quite hard (What DO you do when the filter of a where statement throws an exception?)  and I'm not sure if it is worth the extra weight.

I hope you keep enjoying it and any suggestions are welcome,



Dec 1, 2009 at 12:54 PM

Right, expression nodes like blocks, loops, etc. cannot be reliably observed.  There might be some improvements to some of the member/list binding and initialization expressions, though.  I'm not really sure, I was just wondering if you'd spent any time with them yet :).

On an unrelated note, have you had a chance to look at the Reactive Extensions (Rx)?  They might prove useful for your work on this project.  FYI, the IObservable/IObserver interfaces are being included in .NET 4.0.



Dec 9, 2009 at 6:38 AM

Hi Thomas,

Firstly, great work with the library! You've certainly surpassed the CLinq & BLinq projects in terms of functionality. The other projects have become stale and are poorly maintained in comparison. In addition to this you fully support all of the SelectMany overloads and the Join operator! Well done!

I think project would be very popular had you picked a catchier (name perhaps tying the project to LINQ more, however I understand this is not just LINQ).

I agree with Mike in that there is defiantly some overlap here with .NET Rx. IValueProvider seems to perform a similar function IObservable.

I'll be keeping an eye on this project.

James Miles

Dec 9, 2009 at 8:34 PM
Edited Dec 9, 2009 at 8:35 PM

Well; thanks for the boosting comments. :-)

You are right; there is deffinitely a functional overlap between Obtics and .NET Rx. That said; there are also some big differences. Event pushing in Obtics is quite simple so I don't think Rx would add anything to Obtics internally.

Jan 9, 2010 at 12:10 PM

I was thinking that supporting IObservable<T> would be useful for custom observable methods.  If a .NET developer could leverage his existing knowledge of Rx to write methods that return IObservable<T> instead of IValueProvider<T>, it would reduce the learning curve and enable the developer to harness some of the powerful APIs in Rx.

Jan 9, 2010 at 12:45 PM

Hi Mike,

The plan is to support IValueProvider, INotifyPropertyChanged and IObservable on value transformations and IVersionedEnumerable, INotifyCollectionChanged and IObservable on collection transformations.

But to be able to do that we will need C# 4.0 support for contra- and covariance. Otherwise we would end up with an overload of overloaded extension methods. GroupJoin for example takes 3 lambdas. Now already these lambdas can eiter return a value or an IValueProvider. This means there are already 2^3 = 8 different overloads of this method. If extension methods would return a type X that supportes IValueProvider, INotifyPropertyChanged and IObservable then the lambdas would need to support that X too. So that would mean 3^3 = 27 different overloads for 1 method.

An other option would be to let IValueProvider support INotifyPropertyChanged and IObservable directly. That doesn't seem very clean though. I think i'd rather wait untill Obtics can switch to C# 4.0.



Jan 9, 2010 at 1:02 PM

Hi Thomas,

Sounds great.  Since IObservable<T> will be included in the .NET 4.0 BCL, it makes sense to wait for that anyway.