Name von Aufzähltypen

[theo]

Wozu ist das gut? Wenn die User 'gelb' lesen sollen, geht das dann mit Konstanten nicht viel einfacher?

Kann es sein, dass sich deine Frage gar nicht so sehr auf die Stringumwandlung bezieht, sonder eher auf den Nutzen der Aufzählungstypen an sich?
https://en.wikipedia.org/wiki/Enumerated_type

[Niesi]

Kann es sein, dass sich deine Frage gar nicht so sehr auf die Stringumwandlung bezieht, sonder eher auf den Nutzen der Aufzählungstypen an sich?
https://en.wikipedia.org/wiki/Enumerated_type

Exakt. Danke für den Link, das ist aufschlussreich.

Das ist alles von früher, richtig?

Das Beispiel im wikipedia mit dem Kartenspiel ließe sich per Objektorientierung doch wesenrlich eleganter und auch verständlicher verwirklichen ...

[theo]

Das ist alles von früher, richtig?

Das Beispiel im wikipedia mit dem Kartenspiel ließe sich per Objektorientierung doch wesenrlich eleganter und auch verständlicher verwirklichen ...

Verstehe die Frage nicht. 1+1=2 ist auch "von früher" und trotzdem brandaktuell.
Und natürlich kann man immer alles anders machen.
Die Aufzählungstypen sind halt einigermassen sicher, komfortabel und effizient.

[Niesi]

Verstehe die Frage nicht. 1+1=2 ist auch "von früher" und trotzdem brandaktuell.
Und natürlich kann man immer alles anders machen.
Die Aufzählungstypen sind halt einigermassen sicher, komfortabel und effizient.

Gut, da hast Du mich erwischt - mein Sohn sagt immer, dass Pascal von früher ist - da argumentiere ich ähnlich wie Du eben gerade ...

Ich muss zugeben, dass ich die Handhabung mit den Enums umständlich finde und auch nicht unbedingt vorteilhaft für die Lesbarkeit des Quelltextes. Da ließe sich mit einem objektorientiertem Ansatz sicher was besseres gestalten.

Aber ok, gibt ja auch Leute, die können nur Sachen von früher - weil ChatGPT nichts neues und kreatives rübergeben kann - eine KI kann eben nur nachplappern.

Aber das ist ein anderes Tema, denke ich ...

Jedenfalls vielen Dank, ich hab was gelernt. Und meine NB ( NB = Natürliche Blödheit ) wieder verringert. Darauf kommt es an ...

[Socke]

Ich muss zugeben, dass ich die Handhabung mit den Enums umständlich finde und auch nicht unbedingt vorteilhaft für die Lesbarkeit des Quelltextes. Da ließe sich mit einem objektorientiertem Ansatz sicher was besseres gestalten.

Enums bekommst du in 1 bis 4 Bytes unter. Objektorientiert brauchst du ein Vielfaches davon. Hängt also von der Aufgabenstellung ab, was "besser" ist.

Hab Deine Antwort zu spät gesehen, musste gerade umsteigen ...

Wozu ist das gut? Wenn die User 'gelb' lesen sollen, geht das dann mit Konstanten nicht viel einfacher?

Ich verstehe das eher so:
Ein Array kann bekanntlich auch mit einem Aufzählungstype deklaliert werden

Code: Alles auswählen

Type
   Farben = (gelb, blau, rot);
   
Var
  arr:Array[Farben] Of String;

Und je nachdem, welche "Sprache" der User für sich eingestellt hat, kann für

Code: Alles auswählen

//User hat deutsch
Writeln(arr[gelb]); //--> output = "gelb"
....
//User hat englisch
Writeln(arr[gelb]); //--> output = "yellow"

kommen, in seinem LOGGING würde aber immer "gelb" stehen, weil er den numerischen Wert "übersetzt"

Das hängt auch von der Aufgabenstellung ab. Willst du Informationen für einen Entwickler ausgeben, sollten die Namen im Log und im Code identisch sein. Ein einfacher Blick in den Objektinspektor zeigt doch, wozu so etwas gut ist.

Für eine benutzerfreundliche Anwendungsoberfläche ist die "Übersetzung" in Anwendungssprache (es muss kein Text sein) aufwändiger, aber einfacher zu verstehen.

[Niesi]

Ich muss zugeben, dass ich die Handhabung mit den Enums umständlich finde und auch nicht unbedingt vorteilhaft für die Lesbarkeit des Quelltextes. Da ließe sich mit einem objektorientiertem Ansatz sicher was besseres gestalten.

Enums bekommst du in 1 bis 4 Bytes unter. Objektorientiert brauchst du ein Vielfaches davon. Hängt also von der Aufgabenstellung ab, was "besser" ist.

...

Das ist klar.

Wenn es darauf ankommt, dann ist sicher Assembler die Wahl, oder?

Ein gut lesbarer Quelltext, der später gut zu warten, leicht zu verstehen und weiter zu entwickeln ist - das ist es doch, worauf es ankommt. Und da kommt zurzeit nichts gegen OOP an ...

[af0815]

Ein gut lesbarer Quelltext, der später gut zu warten, leicht zu verstehen und weiter zu entwickeln ist - das ist es doch, worauf es ankommt. Und da kommt zurzeit nichts gegen OOP an ...

Das war noch nie mit OOP verbunden. Man kann alles und jedes so visualisieren, das es nicht zu lesen ist. Auch das gerne genommen C kann man so oder so schreiben.

[Niesi]

Ein gut lesbarer Quelltext, der später gut zu warten, leicht zu verstehen und weiter zu entwickeln ist - das ist es doch, worauf es ankommt. Und da kommt zurzeit nichts gegen OOP an ...

Das war noch nie mit OOP verbunden. Man kann alles und jedes so visualisieren, das es nicht zu lesen ist. Auch das gerne genommen C kann man so oder so schreiben.

Richtig ist: In jeder Programmiersprache kann vollkommen unverständliches Zeugs zusammengeschustert werden.

Es gibt aber auch Programmiersprachen, die es den Entwickelnden leicht machen, gut lesbaren, gut wartbaren und gut weiter entwickelbaren Code zu schreiben.

Dazu zählt C jedenfalls eher nicht.

Und OOP bringt durch die damit verbundene Logik extrem viele Vorteile, auch die Möglichkeit, es noch besser zu machen. OOP ist ja nicht nur eine andere Methode, es ist eine Weiterentwicklung der Programmierung.

Ich empfand die Einführung von OOP als einen Schritt, der vergleichbar ist mit der Einführung einer Hochsprache anstelle von Assembler ...

[Mathias]

Wen man es als Type hat, kann man die ganze Reihe ausgeben:

Code: Alles auswählen

type
  TCmd = (cmdRemove, cmdRemoveAll, cmdAppend, cmdUp, cmdDown);
var
  cmd: TCmd;
begin
  for cmd := Low(TCmd) to High(TCmd) do begin
    WriteLn(cmd);
  end;
end.  

[af0815]

Wen man es als Type hat, kann man die ganze Reihe ausgeben:

Vorsicht, bei Enums, die Löcher haben (weil manuell Werte vergeben wurden).

[PascalDragon]

Im Plus-Paket wird mir bei gleicher Fragestellung eine andere, ebenfalls funktionierende(!) Lösung ausgespuckt:

Code: Alles auswählen

  uses TypInfo;
  var x: (blau, gelb, rot);
  x := gelb;
  s := GetEnumName( TypeInfo(x), Ord(x) );
  ShowMessage(s); // Writeln(s);  

Ich kannte bisher keine der Lösungsmöglichkeiten, weder über GetEnumName() noch über Str() - also gut, dass es dieses Forum gibt.

Bitte beachte, dass die Variante mit GetEnumName nicht geht, wenn das Enum Lücken hat, da es dann keine gültige Typinformation gibt und daher TypeInfo(<Bezeichner>) nicht kompiliert:

Code: Alles auswählen

program tenum;

{$mode objfpc}
{$scopedenums on}

uses
  TypInfo;

type
  TTestEnum = (a, b, c);
  TTestEnum2 = (a = 1, b, c);

var
  e: TTestEnum;
  e2: TTestEnum2;
  s: String;
begin
  e := TTestEnum.b;
  e2 := TTestEnum2.b;
  Str(e, s);
  Writeln(s);
  Str(e2, s);
  Writeln(s);
  s := GetEnumName(TypeInfo(e), Ord(e));
  Writeln(s);
  // error: No type info available for this type
  {s := GetEnumName(TypeInfo(e2), Ord(e2));
  Writeln(s);}
end.

[Mathias]

Bitte beachte, dass die Variante mit GetEnumName nicht geht, wenn das Enum Lücken hat, da es dann keine gültige Typinformation gibt und daher TypeInfo(<Bezeichner>) nicht kompiliert:

Diese Lücken finden man unter C recht oft.

[Warf]

Und OOP bringt durch die damit verbundene Logik extrem viele Vorteile, auch die Möglichkeit, es noch besser zu machen. OOP ist ja nicht nur eine andere Methode, es ist eine Weiterentwicklung der Programmierung.

Ich empfand die Einführung von OOP als einen Schritt, der vergleichbar ist mit der Einführung einer Hochsprache anstelle von Assembler ...

Naja mittlerweile geht man wieder weg von OOP, denn OOP bringt auch extrem viele Nachteile. Z.b. durch das verwenden von abstrakten Methoden weiß man nur vom anschauen des Codes nicht welcher code wann ausgeführt wird, was es unfassbar schwer macht nachzuvollziehen was code tatsächlich macht.

Während einige Ideen von OOP nach wie vor sehr beliebt sind, gehen die meisten sprachen Mittlerweile weg von Vererbung und wenden stattdessen ein composition schema an.

Zum Thema enums, enums sind in vielen Situationen die richtige Variante, schau dir z.b. Canvas.Pen an. Color, Style, Mode, etc. Sind alles enums, wie sollte man das mit OOP lösen? Eine subklasse für jede Kombination an Farbe, Style und mode erstellen? Das gibt Million von klassen

[Zvoni]

Sind alles enums, wie sollte man das mit OOP lösen? Eine subklasse für jede Kombination an Farbe, Style und mode erstellen? Das gibt Million von klassen

Womit wir dann (mehr oder weniger) bei Dot Crap wären.....

[Mathias]

Naja mittlerweile geht man wieder weg von OOP, denn OOP bringt auch extrem viele Nachteile. Z.b. durch das verwenden von abstrakten Methoden weiß man nur vom anschauen des Codes nicht welcher code wann ausgeführt wird, was es unfassbar schwer macht nachzuvollziehen was code tatsächlich macht.

Was meinst du mit wegkommen ?
Ohne Objectorientierung ist kaum eine GUI Programmierung möglich.
Oder meinst du, man geht mehr in die Richtung, wie es C-Libs machen. Beispiel SDL, GTK, etc. ?