Wieso darf eine abstrakte Attribut-Klasse nicht generisch sein?

30/12/2009 - 17:36 von Markus Springweiler | Report spam
Hallo,

weiß jemand ob die, in meinen Augen künstliche, Beschrànkung C# spezifisch
ist, oder von der CLR nicht unterstützt werden würde?

Solange eine nicht-abstrakte abgeleitete Klasse alle generischen Parameter
explizit konkretisiert, dürfte es doch eigentlich keine Probleme bei der
spàteren Verwendung geben: ?

public class TestAttribute : AbstractGenericAttribute<int> { }

/\/\arkus.
 

Lesen sie die antworten

#1 Immo Landwerth
30/12/2009 - 18:41 | Warnen spam
On 30.12.2009 17:36, Markus Springweiler wrote:

weiß jemand ob die, in meinen Augen künstliche, Beschrànkung C# spezifisch
ist, oder von der CLR nicht unterstützt werden würde?

Solange eine nicht-abstrakte abgeleitete Klasse alle generischen Parameter
explizit konkretisiert, dürfte es doch eigentlich keine Probleme bei der
spàteren Verwendung geben: ?

public class TestAttribute : AbstractGenericAttribute<int> { }



Damit dieser Eintrag besser gefunden werden kann: die Rede ist von
diesem C# Compilerfehler:

CS0698: A generic type cannot derive from 'Attribute' because it is an
attribute class".

Es gibt diesbezüglich auch einen Eintrag auf Connect:

[Remove C# attribute restrictions, including generics and argument types]
http://connect.microsoft.com/Visual...ackIDB5856

Ich finde es nachvollziehbar, das offene generische Type nicht als
Attribut verwendet werden können -- das würde die Implementierung zum
persistieren der Attribut vermutlich erheblich verkomplizieren.

Warum dies allerdings auch geschlossene generische Typen betrifft,
erschließt sich mir so direkt aber noch nicht. Ich könnte mir entfernt
vorstellen, dass die Argumentation àhnlich làuft. Nur weil ein
generischer Typ geschlossen ist, bedeutet das ja nicht, dass er kein
generischer Typ mehr ist. Wenn man z.B. mittels Reflection die
Klassenhierarchie analysiert, so kann man immer noch nachvollziehen, an
welcher Stelle und wie der generische Typ instanziiert wurde. Dazu sind
eine Reihe nicht trivialer Datenstrukturen in der Runtime erforderlich.
Diese wollte man sich vielleicht für die Attributverwaltung ersparen.

Das làge die Vermutung nahe, dass ein solches Konstrukt nicht CLS
konform ist. In der Ecma 335 (dem CLI Standard [1]) habe ich allerdings
bei Custom Attributes nichts darüber finden können. Eine Volltextsuche
brachte allerdings diesen Absatz zu Tage:



7.2.3 CLS extender

Define new CLS-compliant (non-generic) types that extend any
(non-sealed) CLS-compliant base type. Valid base types include normal
(non-generic) types and also fully constructed generic types.


Nach meiner Interpretation von obigem Satz spràche laut Standard also
eigentlich nichts gegen die Verwendung -- solange der resultierende Typ
vollstàndig instanziiert (also geschlossen) ist.

Das die C# Jungs diese Beschrànkung also quasi "künstlich" erzeugt
haben, mag zwar im ersten Moment absurd erscheinen, könnte aber
tatsàchlich der Fall sein. Das C# Team hat schon in der Vergangenheit
gezeigt, dass sie Einfachheit über universelle Verwendbarkeit stellen.
Es könnte auch schlicht Pragmatismus sein, wenn es die Implementierung
des Compilers vereinfacht.

Denn sind wir mal ehrlich: so generisch wird das T für Attribute nicht
werden können: Der Compiler mag letztlich nur Typen für T, für die er
ein Literal bereithàlt.

Ich habe es nicht ausprobiert, aber eventuell kannst Du solche Attribute
mittels ILASM generieren. Zum linken kannst Du dann z.B. einen der
folgenden Ansàtze verwenden:

a) Die Attribute einfach in ein eigenes Assembly auslagern.
b) Die Attribute in ein eigenes Modul auslagern.
c) a) und nachher mittels ILMerge Deine Assemblies verschmelzen.

Alles nicht schön, aber derzeit der einzige Workaround, der mir
einfàllt, sofern Du wirklich generische Klassen als Attribut verwenden
willst. Wenn Du den generischen Teil als Interface rausziehen kannst,
hilft Dir vielleicht auch der Hinweis im Community Content zur C#
Fehlermeldung:

[Compiler Error CS0698, C# 2.0]
http://msdn.microsoft.com/en-us/lib...2ax10.aspx

HTH

[1] Common Language Infrastructure (CLI) Partitions I to VI, pp. 13
http://www.ecma-international.org/p...a-335.htm,

Immo Landwerth

Ähnliche fragen