Wozu sind Attribute gut ?

[Der schöne Günther]

Das blöde ist nur, dass in

SetPropValue(LField.GetValue(Self).AsObject, 'Color', ColorElementAttribute(LAttr).Color); der Name der Property noch einmal redundant als String hinterlegt ist. Möchte ich den Namen der Property ändern, wäre ich so faul, das direkt mittels Refactoring-Funktionen zu erledigen. Das ändert direkt überall den Namen, wo die Property verwendet wird. Der String bleibt dabei natürlich unangetastet. Und fortan finde ich unter diesem Namen keine Property mehr.

Auch die "alte RTTI" bietet nur das Finden über den Namen als String an. In anderen Sprachen habe ich auch nie wirklich etwas mit Reflection gemacht, ist das dort auch so?

Mich bringt das um ehrlich zu sein ziemlich aus dem Konzept.


Das mit der Enumeration ist ein interessanter Weg, das lasse ich mir mal durch den Kopf gehen

[Elvis]

In C# macht man so etwas mit Expression trees, da sie refactoring-safe sind.

Eine naive Implementierung frei Schnauze:

Code:

public static string GetName<TResult>(Expression<Func<TResult>> expression)
{
   var me = expression.Body as MemeberExpressin;
   if(me != null)
     return me.Member.Name;

   var mce = expression.Body as MetodCallExpressin;
   if(mce != null)
     return mce.Method.Name;
   

   throw ....
}

var methodName = Xyz.GetName(() => "".Substring(0, 1)); // ergibt "Substring"

Auf die Art kann man sich auch direkt PropertyInfos oder MethodInfos (vor allem den korrekten Overload) geben lassen. Sollte man aber möglichst so machen, dass es nicht unnötig oft passiert. Type-safe ist nett, aber schnell ist auch wichtig.

[Stevie]

Zitat von Elvis:

Auf die Art kann man sich auch direkt PropertyInfos oder MethodInfos (vor allem den korrekten Overload) geben lassen. Sollte man aber möglichst so machen, dass es nicht unnötig oft passiert. Type-safe ist nett, aber schnell ist auch wichtig.

Ein

Code:

var name = typeof(Foo).GetProperty("Bar").Name;

ist nicht schneller als über die Expression.

Zitat von Der schöne Günther:

Aber daran haben ja jetzt weniger die Attribute, sondern der Compiler an sich "Schuld". Vielleicht ändert sich das eines Tages ja mal. Die Class Helper und Dinge wie "42.toString()" sagen mir irgendwie, dass Hoffnung besteht

Nicht wirklich, denn die Implementierung dahinter ist eher schmuddelig. Ich wünsche mir ja schon lange property references oder besser noch member references.
Aber dazu müsste einiges am Compiler aufgebohrt werden - was aber nicht zuletzt einiges der arg hässlichen Implementierung der LiveBindings (jupp, die gehen komplett über magic string basierte RTTI) unnötig machen würde.

[Elvis]

Zitat von Stevie:

Ein

Code:

var name = typeof(Foo).GetProperty("Bar").Name;

ist nicht schneller als über die Expression.

Jump, ist genau so lahm.

[jaenicke]

Zitat von Der schöne Günther:

Auch die "alte RTTI" bietet nur das Finden über den Namen als String an. In anderen Sprachen habe ich auch nie wirklich etwas mit Reflection gemacht, ist das dort auch so?

Worüber willst du sie denn sonst ansprechen? Property-Referenzen kennt der Compiler nicht. Theoretisch kann man sich dafür etwas basteln... z.B. auch über Attribute. Indem man in einem Attribut hinterlegt, dass es sich dabei um die Farbe handelt. Dann kann man die Property suchen, die die Farbe repräsentiert. Für sinnvoll halte ich das allerdings weniger.

[Union]

Man könnte sich ja einen Class Helper basteln der die Typeinfo für das die Farbe darstellende Element zurückgibt

[Der schöne Günther]

Zitat von jaenicke:

Property-Referenzen kennt der Compiler nicht.

Eben, mir fällt auch absolut nichts ein, wie man dem Compiler etwas von "der Property an sich" erzählen könnte, indem man nur sie selbst anfasst, und nicht noch ihren Namen in einem String aufschreiben muss.

Aber daran haben ja jetzt weniger die Attribute, sondern der Compiler an sich "Schuld". Vielleicht ändert sich das eines Tages ja mal. Die Class Helper und Dinge wie "42.toString()" sagen mir irgendwie, dass Hoffnung besteht