Wozu sind Attribute gut ?

[OlafSt]

Hallo Freunde,

beim Studium der Sprach-Eigenschaften von Delphi bin ich über die Annotations (Attribute) gestolpert. Das sind diese Dinger hier:

Delphi-Quellcode:

type
   TMyAttr = class
      FData: string;
   constructor Create(AData: string);
   //Implementierung des constructors schenken wir uns mal

type
   TMyClass = class
   [MyAttr('Hallo da draussen')]
   constructor Create;
end;

Ich frage mich, welchen ernsthaften Nutzen ein solches Konstrukt wohl haben mag - zumal der Zugriff auf diese Attribute nicht gerade simpel ist. Wer kann mir da auf die Sprünge helfen ?

[Union]

Um Eigenschaften abfragen zu können. Ich vermute es handelt sich um die Vorarbeiten zu den unsäglichen Livebindings. Ansonsten ist aber der Zugriff über z.b. TRttiContext.GetTypes.GetMethods.GetAttributes doch trivial.

[Uwe Raabe]

Beispielsweise verwendet DataSnap die Attribute um Zugriffsberechtigungen auf Klassen bzw. Methoden-Ebene zu implementieren. Ich wüsste nicht, wie man das eleganter im Code unterbringen sollte. Es ist fast so, als ob man public/private zur Laufzeit einstellen kann.

[jaenicke]

Man kann damit auch sehr elegant z.B. Konfigurationsklassen erstellen, die über die Informationen in den Attributen mit Daten gefüttert werden. Sprich man kann darüber dann das Mapping zur Konfiguration definieren, also wo der Wert in der Konfiguration steht.

Zitat von Union:

Um Eigenschaften abfragen zu können. Ich vermute es handelt sich um die Vorarbeiten zu den unsäglichen Livebindings.

Das wäre schön gewesen, aber leider wurden die LiveBindings viel zu oberflächlich in Delphi integriert, zumindest anfangs. Bei XE4 z.B. habe ich mir die zwar noch nicht angeschaut, aber wenn es da eine größere Änderung in der Implementierung an sich gegeben hätte, hätte ich das vermutlich mitbekommen. Dass sich da einiges getan hat, habe ich schon gesehen, aber soweit ich weiß alles nur was die Verwendung angeht, nicht die Umsetzung.

[Der schöne Günther]

Zitat von Uwe Raabe:

Beispielsweise verwendet DataSnap die Attribute um Zugriffsberechtigungen auf Klassen bzw. Methoden-Ebene zu implementieren.

Zitat von jaenicke:

Mapping zur Konfiguration definieren, also wo der Wert in der Konfiguration steht.

Attribute stehen bislang auch auf meiner Liste "Wie funktioniert das in Delphi?", das ist, was ich spontan geraten hätte bzw. wofür ich es versucht hätte einzusetzen: O/R-Mapping. Einmal eine Serialisierungsmethode gebaut die alle Properties durchgeht, und nur welche mit einem bestimmten Attribut werden persistiert, vorher verändert, mit anderen verknüpft, was auch immer. Das könnte man ja alles darüber steuern....

[Patito]

Zitat von OlafSt:

Hallo Freunde,
Ich frage mich, welchen ernsthaften Nutzen ein solches Konstrukt wohl haben mag - zumal der Zugriff auf diese Attribute nicht gerade simpel ist. Wer kann mir da auf die Sprünge helfen ?

Der Sinn von Attributen in Programmiersprachen ist eigentlich der, dass der Compiler schon zur Compilezeit Methoden zusammenstückeln kann (mache etwas für alle Felder mit Atribut X, ...). Dadurch kann man dann eine Menge Schreibarbeit und Checks zur Laufzeit sparen. So wie das von Embarcadero aber implementiert ist, sind das aber nur Konstanten/Variablen, die etwas "anders" sind.

Für ORMs sind die Dinger soweit ich sehe unbrauchbar, da die ganzen Checks für die Attribute zur Laufzeit geschehen. Das macht das ganze dann deutlich langsamer, als wenn man das gleich richtig ausprogrammiert. Die Attribute sparen so nur in eher exotischen Fällen ein wenig Schreibarbeit (auf Kosten der Geschwindigkeit).

Die Syntax ist auch eher fragwürdig. Wenn man sich mit Delphi auskennt würde man eigentlich erwarten, dass sich das Attribut in deinem Beispiel (wie bei Interface-GUIDs) auf class bezieht.

Der Hauptnutzen von Attributen ist wohl (für Embarcadero) der, dass man damit Konstrukte in die Sprache bekommt, die dann mit anderen Compilern nicht mehr gehen (Vendor lock-in). Technisch sind die Attribute so wie sie jetzt sind eher nicht sinnvoll.

[OlafSt]

Ich verstehe den möglichen Sinn hinter solchen Attributen. Augenscheinlich aber ist die Delphi-Implementierung nur eine Art "Vorstufe", die richtige, vollumfängliche kommt dann mit XE5 oder XE6

Danke für die Antworten, wieder was dazu gelernt - und das nach 30 Jahren als Programmierer

[Phoenix]

Zitat von Patito:

Der Sinn von Attributen in Programmiersprachen ist eigentlich der, dass der Compiler schon zur Compilezeit Methoden zusammenstückeln kann (mache etwas für alle Felder mit Atribut X, ...). Dadurch kann man dann eine Menge Schreibarbeit und Checks zur Laufzeit sparen. So wie das von Embarcadero aber implementiert ist, sind das aber nur Konstanten/Variablen, die etwas "anders" sind.

Dafür sind wie wenigstens Attribute gedacht.

Zitat von Patito:

Für ORMs sind die Dinger soweit ich sehe unbrauchbar, da die ganzen Checks für die Attribute zur Laufzeit geschehen. Das macht das ganze dann deutlich langsamer, als wenn man das gleich richtig ausprogrammiert. Die Attribute sparen so nur in eher exotischen Fällen ein wenig Schreibarbeit (auf Kosten der Geschwindigkeit).

Quatsch. Genau für sowas sind Attribute da. Attribute sollen auf Typen Meta-Informationen bereitstellen die dann später dynamisch zur Laufzeit ausgewertet können - und zwar ohne jeden Typen explizit imstanziieren zu müssen. Die alte Methode wäre, ein Flagging Interface zu verwenden (reine Attributpräsenz auf einer Klasse) und wenn man zusätzliche Informationen über Members bräuchte müsste man eine Instanz erzeugen und über die Methoden / Properties des Interfaces (die man jedes mal implementieren müsste) diese Informationen abzufragen.

Der Zugriff auf Attribute ist auch nicht wirklich langsam. Klar muss die runtime ein wenig suchen und laden, aber das macht man ja nicht permanent sondern genau ein einziges mal und cached die Informationen wenn man sie später nochmal braucht in Memory. Und zwar dort, wo sie gebraucht werden.

Zitat von Patito:

Die Syntax ist auch eher fragwürdig. Wenn man sich mit Delphi auskennt würde man eigentlich erwarten, dass sich das Attribut in deinem Beispiel (wie bei Interface-GUIDs) auf class bezieht.

Nein? Die Syntax ist genau so wie man sie von Java und .NET-Sprachen seit Jahren kennt. Attribut über das zu annotierende Element, in eckigen Klammern. That's it. Keine Magic.

Zitat von Patito:

Der Hauptnutzen von Attributen ist wohl (für Embarcadero) der, dass man damit Konstrukte in die Sprache bekommt, die dann mit anderen Compilern nicht mehr gehen (Vendor lock-in). Technisch sind die Attribute so wie sie jetzt sind eher nicht sinnvoll.

Entweder hast Du den Sinn und Nutzen von Attributen an sich wirklich nicht verstanden, oder Du willst nur Trollen. Nach diesem letzten Absatz würde ich tatsächlich eher auf letzteres schliessen.

Alle anderen modernen typisierten Sprachen haben Attribute um es den Entwicklern zu erlauben eigene Meta-Informationen auf Typen und Member zu legen. Um damit dynamisch Dinge zu bauen die ohne solche Informationen nicht möglich wären. Ein Vendor Lock-In ist bei Delphi im übrigen gar nicht möglich. Delphi ist keine Standardisierte Sprache und reines Pascal ist das schon lange nicht mehr. Delphi an sich ist ein einziger Vendor-Lock-In. Und FreePascal als einzige einigermaßen kompatible Alternative sieht auch schon länger Attribute vor (auch wenn sie noch nicht fertig implementiert sind, oder sind die inzwischen schon drin? Mein Stand hier ist ein halbes Jahr alt).

[Der schöne Günther]

Ich sitze mit großen Augen still in der Ecke und lausche. Vielen Dank für weiteres Material, interessantes Thema!

[Patito]

Zitat von Der schöne Günther:

Ich sitze mit großen Augen still in der Ecke und lausche. Vielen Dank für weiteres Material, interessantes Thema!

Nunja, sonderlich viel Material wird es da nicht mehr geben
1) Für die von Dir genannten Anwendungsfälle ORM/Serialisierung ist es eben etwas ungeschickt die
Methode jedes mal zur Laufzeit zusammenzustückeln. Wenn man das ganze gleich richtig macht ist man
eben gleich eine Größenordnung schneller. Attribute sparen da eben nur etwas Tipparbeit (für Code,
den man gerade beim solchen Anwendungsfällen eh vollautomatisch erzeugen kann).

2) Die Syntax ist eben Java/C# und passt nicht ganz zu Pascal.

3) Man hat für den Code nicht mehr sonderlich viele Compiler zur Auswahl.