search

theraot / Theraot

Backporting .NET and more: LINQ expressions in .net 2.0 - nuget Theraot.Core available.
MIT License
158 stars 30 forks source link

Minimal changes to support Expression.GetDelegateType #111

Closed lbmaian closed 4 years ago

lbmaian commented 4 years ago

See #110

Implemented as ExpressionEx.GetDelegateType for .NET Framework 3.5 build only. Pre-3.5 and Post-3.5 users will continue to see it as Expression.GetDelegateType.

There's actually a whole bunch of LINQ/Expression stuff that's in 4.0 but not in 3.5, such that oddly enough, pre-3.5 users of Theraot have more a complete LINQ/Expression implementation than 3.5 users. I had to make minimal changes, or otherwise I would've pulled in a lot of extra baggage, including a lot of 4.0+ Dynamic support.

theraot commented 4 years ago

Not like this, the whole point is to make it so that user do not need conditional compilation. If I am adding an ExpressionEx, I am adding it for all builds.

lbmaian commented 4 years ago

So does that mean that GetDelegateType should be on both Expression and ExpressionEx, such that it is always on ExpressionEx regardless of build, and essentially on Expression for all builds except for Framework 3.5? GetDelegateType can't simply be moved to ExpressionEx since it would break pre-3.5 users relying on it being on Expression.

theraot commented 4 years ago

So does that mean that GetDelegateType should be on both Expression and ExpressionEx, such that it is always on ExpressionEx regardless of build, and essentially on Expression for all builds except for Framework 3.5?

If ExpressionEx is the solution, then yes, GetDelegateType would be exposed twice. ExpressionEx.GetDelegateType would delegate to Expression.GetDelegateType when possible, and we can mark it with [MethodImpl(MethodImplOptionsEx.AggressiveInlining)]. See for example ArrayEx.