Issue 28 in linqbridge: Move ExtensionAttribute into a separate assembly

[linqb...@googlecode.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 28 by firegura...@gmail.com: Move ExtensionAttribute into a
separate assembly
http://code.google.com/p/linqbridge/issues/detail?id=28

At this point where is a lot of libraries which employs an
ExtensionAttribute definition hack to support .NET, which leads to some
well-known problems when System.Runtime.CompilerServices.ExtensionAttribute
gets redefined in more when one assembly. For example, let's consider the
following situation I faced recently: my project referenced both LinqBridge
and Json.NET which has its own built-in *internal* copy of LinqBridge (with
ExtensionAttribute defined *internal* too). This resulted in an "error
CS0656: Missing compiler required
member 'System.Runtime.CompilerServices.ExtensionAttribute..ctor'" and made
me to recompile Json.NET to reference LinqBridge explicitly.

So, what about moving ExtensionAttribute definition into a completely
separate assembly, maybe even into a completely separate project? AFAIR,
LinqBridge is the most notable project which uses this tricky technique,
and I hope other libraries would eventually switch to that assembly instead
of defining their own copy of the attribute class, and there would be the
only one assembly with ExtensionAttribuite for .NET 2.0, providing
the "standard" implementation the hack.

See also:
http://stackoverflow.com/questions/11025100
http://devhawk.net/2012/06/20/ambiguous-extensionattribute-errors/


--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[linqb...@googlecode.com]

Updates:
Status: WontFix

Comment #1 on issue 28 by azizatif: Move ExtensionAttribute into a separate
assembly
http://code.google.com/p/linqbridge/issues/detail?id=28

You should take up this issue with Json.NET. The idea of LINQBridge was to
provide .NET 3.5-isms for .NET 2.0, which, besides LINQ, includes extension
methods. In fact, the ExtensionAttribute was internalized in 1.1 and then
deliberately brought back in 1.2 (see issue #10).

[linqb...@googlecode.com]

Comment #2 on issue 28 by firegura...@gmail.com: Move ExtensionAttribute

into a separate assembly
http://code.google.com/p/linqbridge/issues/detail?id=28

> The idea of LINQBridge was to provide .NET 3.5-isms for .NET 2.0, which,
> besides LINQ, includes extension methods.

LINQ is the most known application of extension methods, but not the only
one. It may
be a good idea to split "providing extension methods for .NET 2.0"
and "providing
LINQ to Objects for .NET 2.0", because they are *different* languages
features, where
the latter is based on the former. There may be other libraries which would
like to
use extension methods facility which have nothing to do with LinqBridge. If
they all
declare their own ExtensionAttribute, they may get unusable together with
each other.

> In fact, the ExtensionAttribute was internalized in 1.1 and then
> deliberately brought back in 1.2 (see issue #10 ).

I didn't mean it should be internalized. It should be public, but moved
away from LinqBridge assembly into a separate DLL what would be shipped
with it. Something
like this:

* LinqBrigde.dll references ExtensionAttribute.dll
* LibraryThatNeedsExtensionMethodsWithLinq.dll references LinqBridge.dll
* LibraryThatNeedsExtensionMethodsButNotLinq.dll references
ExtensionAttribute.dll

[linqb...@googlecode.com]

Comment #3 on issue 28 by azizatif: Move ExtensionAttribute into a separate
assembly
http://code.google.com/p/linqbridge/issues/detail?id=28

I understand where you're coming from. You can also extend the same
argument to Action and Func delegates. In any event, this would change the
direction with which LINQBridge was conceived. Today, it is a project in
twilight and the only effort made would be, I reckon, towards a showstopper
bug. Anything else would require considerable resources that are scarce,
like volunteered free time. That said, LINQBridge is open source and if you
are confident it needs to make the split, it can be forked (under the same
license), changed and re-published on NuGet under an alternate Id.

[linqb...@googlecode.com]

Comment #4 on issue 28 by firegura...@gmail.com: Move ExtensionAttribute

into a separate assembly
http://code.google.com/p/linqbridge/issues/detail?id=28

> You can also extend the same argument to Action and Func delegates.

This would be an overkill. Moreover, multiple Action and Func delegates
may be declared in different namespaces, one for each library which
wants then, and they would be still compatible each with other,
unlike ExtensionAttribute which MUST reside in system namespace.

> LINQBridge is open source and if you are confident it needs to make
> the split, it can be forked (under the same license), changed and
> re-published on NuGet under an alternate Id.

The key point was to create a common assembly for everyone who wants
to employ extension methods in .NET 2.0, so that assembly must come
from an authoritative source like LinqBridge. Even if I'm going to
fork the project, it will not convince anybody to use that assembly.

> Today, it is a project in twilight

Sad but true. Almost no one cares about .NET 2.0, but some libraries
still try to support it. If there would be a common and widely
acceptable way of using extension methods which will prevent conflicts
between these libraries (caused by ExtensionAttribute), then their
authors would not just terminate that support because they got tired
of bug reports from users of old runtime.

Anyway, thank you for your answers. I'm also sorry for my not very
perfect language.