resourcestring nicht in Klassen oder Records erlaubt?

[Der schöne Günther]

Bin ich dumm oder geht folgendes schlichtweg nicht?

Delphi-Quellcode:

TMyClass = class
   protected resourcestring
      myConst = 'Hallo Welt';
end;

[Medium]

Wenn mich nicht alles täuscht, werden resourcestrings eben genau als solches einkompiliert: Als resource. Diese haben prinzipbedingt erstmal keine Zugehörigkeit zum OOP Konzept, und werden darin sehr wahrscheinlich auch nicht unterstützt.

Ich wäre nichtmals auf die Idee gekommen überhaupt Konstanten in einem Klassenkontext zu verwenden. Geht das überhaupt mit "normalen" Konstanten? Wenn ja: Wo würde man so etwas sinnvoll einsetzen? Im Scope eines Namespace (bzw. einer Unit) okay, aber als Teil einer Klasse? Vor allem: Wenn, dann müsste es ja als Klassen-Konstante implementiert sein, sonst könnte ja jede Instanz seine eigene haben, was wiederum dem Begriff "Konstante einer Klasse" entgegen stünde. Vor allem, wo würde man diese dann definieren? Zuweisen geht ja nicht (puristisch gesehen, technisch vermutlich schon). Ich zumindest bin noch keiner Situation begegnet, wo ich das Bedürfnis nach solch einem Konstrukt gehabt hätte, bin aber offen für Ideen

[Stevie]

Zitat von Medium:

Ich wäre nichtmals auf die Idee gekommen überhaupt Konstanten in einem Klassenkontext zu verwenden. Geht das überhaupt mit "normalen" Konstanten? Wenn ja: Wo würde man so etwas sinnvoll einsetzen? Im Scope eines Namespace (bzw. einer Unit) okay, aber als Teil einer Klasse? Vor allem: Wenn, dann müsste es ja als Klassen-Konstante implementiert sein, sonst könnte ja jede Instanz seine eigene haben, was wiederum dem Begriff "Konstante einer Klasse" entgegen stünde. Vor allem, wo würde man diese dann definieren? Zuweisen geht ja nicht (puristisch gesehen, technisch vermutlich schon). Ich zumindest bin noch keiner Situation begegnet, wo ich das Bedürfnis nach solch einem Konstrukt gehabt hätte, bin aber offen für Ideen

Bei einer Konstante in einer Klasse/Record bezieht sich das einzig auf den Scope sonst nix. Wenn du innerhalb einer Klasse einen bestimmten konstanten Wert mehrfach benötigst und nicht mit magic numbers in deinem Code rumschmeißen und die Möglichkeit haben möchtest diesen Wert an einer Stelle zu ändern, bietet sich eine const in dieser Klasse durchaus an. Klar, kannste die auch ganz oldschool in den Implementation Teil deiner Unit packen, aber dann hat sie nicht genau den Scope, den du eigentlich bezweckst.

[himitsu]

Das ist wie bei Sub-Typen.

So hat man Typen, Konstanten, Propert/Variablen alle logisch zusammen und kann sie über die Codevervollständigung auch schön suchen lassen.
z.B. keine doppelten Prefixe und genau das finden, was man will ... z.B. siehe die neuen TColorRec-Werte (OK, per Record Helper wären sie wirklich genau da wo sie hingehören).

[Medium]

Hmm, ich verstehe die Argumente durchaus. Dennoch mutet mir das konzeptionell komisch an. Vielleicht auch, weil ich doch fast immer durchhalte eine Klasse pro Unit zu machen, und die Konstanten dann später bei potenziellen Konflikten via Namespace qualifiziere, was am Ende ja relativ ähnlich raus kommt. Aber ich verstehe durchaus die grundlegende Motivation - okay!

[Elvis]

Solche Dinge sind ja öfter Implementierungsdetails als gewollt öffentlich sichtbare Informationen.
Und als Implementierungsdetails haben sie auch nix im öffentlichen Interfaces des Codes zu suchen.
Günthers Bleistift ziegt hier schön, dass man es so auch in Nachfahren der Klassen nutzen könnte.

Mit den aktuellen Einschränkungen muss er es wohl als resource string im "implementation"-Teil deklarieren und per protected static class function an Nachfahren weiterreichen.
Tut nicht weh, aber ich hätte gedacht, dass man mittlerweile ohne globale Dinger in Delphi auskommen kann...

[himitsu]

Zitat von Medium:

Vielleicht auch, weil ich doch fast immer durchhalte eine Klasse pro Unit zu machen,

Das mach ich im Prinzip auch.

Aber wenn ich z.B. interne Klassen benötige, oder 'ne SubKlasse für eine Property-Gruppe, dann lege ich

Interne Klassen kann man ja theoretisch auch im Implementations-Teil deklarieren, aber nur, wenn man den Typ nicht schon für eine Referenz in der oberen Klassendeklaration benötigt.


Internes dann als private/protected und Untergeordnetes als public.
Inzwischen kommt auch noch eine Region um diese Sachen drumrum, so stören diese Dinge und die privaten/protected Methoden, sowie die Felder nicht mehr den Lesefluß, was recht praktisch ist, wenn man den Code gleich mit als Dokumentation verwendet, da so der Blick erstmal nur auf die öffentlichen Methoden/Property fallen kann.