Wenn man sich was wünschen dürfte...

[stahli]

Unabhängig von konkreten und existierenden Programmiersprachen habe ich mal einige grundsätzliche Überlegungen bzw. Fragen, was Ihr generell als sinnvoll bzw. zweckmäßig ansehen würdet.

Ich will hier keine Pascal-Änderungen anregen, sondern einfach mal ein paar grundsätzliche (quasi philosophische) Überlegungen anstellen und diskutieren - wem das gelingt auch gern unter Berücksichtigung der Sicht eines Programmieranfängers.

„Das war aber schon immer so“ und „das kennt man halt so“ wären natürlich legitime Standpunkte, mir geht es aber darum, was der sinnvollere Ansatz ist. In dem Fall würde ich die Fragen halt so stellen: Hätte man nicht damals besser….


1) 1-basierte Listen

Ich fände generell 1-basierte Listen sinnvoll.
Wenn ich 3 Autos habe, dann zähle ich die abends in der Garage ja auch immer von 1 an durch.
In einer Hochsprache finde ich 0-basierte Listen umständlich und unnötig.


2) Werte- und Referenzzuweisungen

Delphi-Quellcode:

I1, I2: Integer;
I2 := I1; // kopiert den Wert. Änderungen in I1 wirken sich nicht auf I2 aus und umgekehrt

P1, P2: TPerson;
P2 := P1; // kopiert den Zeiger, also "beinhalten" P1 und P2 das gleiche Objekt (die gleiche Person). Änderungen „in P1“ (Vornamenänderung) wirken sich auch auf P2 aus und umgekehrt.

Wäre es generell nicht sinnvoll, das zu vereinheitlichen?

Delphi-Quellcode:

I2 := I1; // kopiert den Wert
I2 -> I1; // lässt I2 den Inhalt von I1 referenzieren

P2 := P1; // würde eine Objektkopie erzeugen (andere Speicherstelle (und wenn das Objekt über eine ID verfügt auch andere ID) , wobei alle Propertys (einschließlich anderen Referenzen wie z.B. Vater und Mutter als Personenobjekte) kopiert würden
P2 -> P1; // lässt P2 den Inhalt von P1 referenzieren

Als Parameter könnte man das ähnlich regeln:

Delphi-Quellcode:

MyProcedure(I: Integer; P: TPerson); // beides KEINE Referenzen sondern Datenkopien
MyProcedure(-> I: Integer; -> P: TPerson); // beides als Referenzen (wie im Delphi var-Parameter)

Allerdings bin ich mir selbst nicht sicher, wie die beste Lösung aussehen sollte.
Der Vorteil des „->“ (gelesen: "referenziert") wäre, dass es zwischen primitiven Werten und Businessobjekten dann nicht mehr unterschiedliche Verfahrensweisen geben würde.
Andererseits würde die klassische Zuweisung von Objektinstanzen nicht (mehr) das tun, was man landläufig kennt.

Delphi-Quellcode:

Person.Chef := Cheffe

würde eben eine Datenkopie von Cheffe erzeugen und zuweisen, was man sicher seltenst benötigt. Viel eher will man wohl tatsächlich i.d.R. ein anderes Objekt referenzieren.
Logisch wäre somit dann

Delphi-Quellcode:

Person.Chef -> Cheffe

Eine Schreibweise mit „:=“ würde bei (Business)Objekten dann so gut wie nicht mehr vorkommen.

Positiv wäre, dass man in Anweisungen und bei Übergabeparametern sowohl bei primitiven Typen als auch bei Businessobjekten immer eine einheitliche Schreib- und Verfahrensweise hätte.


3) Strings im Quelltext

So etwas ist ja ziemlich umständlich:

Delphi-Quellcode:

S := Vorname + ' ' + Nachname + '(' + Ort + ')';

C# bietet so etwas:

Delphi-Quellcode:

S := String.Format("{0} {1} ({2:x})", Vorname, Nachname, Ort) // wobei das x für Formatierungsregeln steht

Wäre es nicht sinnvoll, so etwas zu haben wie:

Delphi-Quellcode:

S := '<Vorname> <Nachname> (<Ort:x>)'

Wenn man noch Regeln unterbringen will wie bedingte Leerzeichen, wird es schon schwieriger:

Delphi-Quellcode:

S := '<Vorname><? ?><Nachname> (<Ort:x>)' // <? ?> steht hier für einen bedingtes Leerzeichen bzw. Text, wenn beide Bezeichner rechts und links keine leeren Strings enthalten

Verkürzt könnte man es noch so schreiben:

Delphi-Quellcode:

S := '<Vorname? ?Nachname> (<Ort:x>)'

(Eine einfache und logische Lösung für den Fall, dass man z.B. die Klammern nur will, wenn der Ort und der linke Text nicht leer sind fällt mir hier erst mal nicht ein. Klassisch würde man ja S1, S2 und S3 als Trenner festlegen und den Ergebnisstring dann zusammenbauen. Das wird man vielleicht nicht umgehen können aber vielleicht kann man bestimmte Standardkriterien durch einfache Regeln abbilden.)

Der Parser müsste natürlich die Klammern interpretieren können.
Der Editor müsste umschaltbar sein, so dass man entweder die Klammern (Formatanweisungen) sieht oder diese ausblendet werden und die Darstellung auf die farbigen Bezeichner reduziert wird.
S := 'Vorname Nachname (Ort)'
(So ähnlich, wie man im Word Felder und Formeln unterschiedlich anzeigen kann.)

[Sir Rufo]

1. 0-basiert ist doch genau richtig.
   
   Gerade wenn man ein Raster in einer Liste unterbringt, dann ist die Berechnung über die Koordinaten super simpel:
   
   Delphi-Quellcode:

   var
     LIdx, x, y : Integer;
   
   LIdx := x + y * ColCount;

   Oder das ganze zurück:
   
   Delphi-Quellcode:

   x := LIdx mod ColCount;
   y := LIdx div ColCount;

2. Delphi-Quellcode:

   x := y;

   ist einheitlich eine Wertzuweisung!. Somit bedarf es hier keiner Änderung.
   
   Die Variable
   Delphi-Quellcode:

   var foo : TObject;

   hat als Wert eine Referenz, darum nennt man die auch Referenz-Variable.
   
3. Gibt es schon in C# 6.0
   
   Code:

   var test = "Moin";
   var str = $"{test}";

[Stevie]

3) String Interpolation - sehr schönes Feature, wie auch die anderen in C# 6.0, die nicht revolutionär sind, aber den Code vereinfachen.

Meine Prognose - wird es in Delphi in den nächsten 10 Jahren nicht geben, weil der Fokus zu sehr auf RAD liegt.
Die Devise: "Null Zeilen Code schreiben, dafür gibts ne Komponente" (die das ganze dann macht und dafür zigtausende Zeilen Framework Code durchläuft)

[mm1256]

Zitat:

Zitat von stahli (Beitrag 1316125)

3) Strings im Quelltext

So etwas ist ja ziemlich umständlich:

Delphi-Quellcode:

S := Vorname + ' ' + Nachname + '(' + Ort + ')';

Ich finde das oftmals sogar praktischer und leicht lesbarer als die Format-Funktion von Delphi. Und wenn's mal Strings mit Trennzeichen oder Begrenzer sein sollen, auch abhängig vom Inhalt des Strings, dann gibt's dafür die eigene kleine Toolsammlung. Die tut dann auch genau das, was ich von ihr erwarte. Als Standard-Funktion würde ich das gar nicht haben wollen.

Aber, wenn ich schon ein paar Wünsche frei hätte, dann würden diese weniger in Richtung Spracherweiterung, sondern mehr in Richtung IDE-Verbesserung gehen. Dann hätte ich z.B. gerne einen Code-Formatierer der meinen Code genauso formatiert wie ich ihn haben will, und mich gleich beim Schreiben entsprechend unterstützt. Der bei Vervollständigung der Prozeduren und Funktionen mit [Strg]+[Shift]+[C] diese nicht alphabetisch anordnet, sondern so wie ich es für richtig erachte: Zuerst Form-Events, dann Komponenten-Events, dann "private" und "public".

[Stevie]

Es geht nicht nur um die Lesbarkeit des Codes sondern auch um die Einfachheit, Strings zu lokalisieren. Lokalisier mal nen string, der aus zig Einzelschnipseln im Code zusammen getackert wird.
"Dafür gibts ja Format", sagt jetzt jemand. Jup, und dann lokalisier doch mal nen String, der da lautet "Der %s %s wohnt in %s" ohne den Kontext zu kennen (vor allem wenn dann noch Sprachen dazu kommen, bei denen die Grammatik anders funktioniert. Ein String, der da lautet "Der {vorname} {nachname} wohnt in {ort}" ist dann wohl unmisverständlich (klar, der übersetzer muss nun nur noch wissen, dass die Dinger, die zwischen {} stehen nicht übersetzt werden, weil das Variablen namen sind. :)

Der einzige Knackpunkt daran wird wohl nur das Refactoring von Variablennamen sein, aber das ist das Problem des Toolings.

[Rollo62]

Ich bin auch für 0-basierte String und StringListen sowieso, ist dann endlich kompatibel zu C/C++ Code.

Ausserdem sind die neuen MobileCompiler sowieso 0-basiert.

Ich baue gerade meine Libraries nach und nach auf 0-basiert um.
Da gibt es schöne TStringHelper ClassHelper die man dafür nehmen sollte.

Rollo

[Bjoerk]

Hattest du dieses Thema nicht schon mal? Bin ganz klar für 1 basiert. Jeder der anfängt zu programmieren, baut Schleifen 1..N. Notfalls könnte man ja das Offset auch angeben (geschieht bei statischen Arrays ja sowieso). Anderseits ist es ja aber auch kein Problem sich seine eigene Classes1 zu schreiben. Habe z.B. ich gemacht, weil mein Statik-Kram 1 basiert ist (historisch bedingt). An den Wertetypen hingegen würde ich nichts ändern.

[p80286]

Zitat:

Zitat von Sir Rufo (Beitrag 1316126)

Delphi-Quellcode:

x := y;

ist einheitlich eine Wertzuweisung!. Somit bedarf es hier keiner Änderung.

Die Variable

Delphi-Quellcode:

var foo : TObject;

hat als Wert eine Referenz, darum nennt man die auch Referenz-Variable.

Dafür muß man das aber auch wissen!
Immer wieder beliebt ist doch auch

Delphi-Quellcode:

  A1 : array[0..5] of word;
  A2 : array of word;
  pWrd : word;

begin
  setlength(A2,6);
  pwrd:=@A1;
  pwrd^:=5;
  pwrd:=@A2;
  pwrd^:=5;
end;

Un nun kommt die Frage "warum steht in A1[0] 5 und in A2[0] nicht?
Das sind doch beides Arrays?"

Gut wir wissen, daß ein dyn.Array etwas anderes ist als ein statisches, aber einem unvoreingenommenen Leser erschließt sich das eben nicht auf den ersten Blick.

Gruß
K-H

[Sir Rufo]

Zitat:

Zitat von p80286 (Beitrag 1316155)

Zitat:

Zitat von Sir Rufo (Beitrag 1316126)

Delphi-Quellcode:

x := y;

ist einheitlich eine Wertzuweisung!. Somit bedarf es hier keiner Änderung.

Die Variable

Delphi-Quellcode:

var foo : TObject;

hat als Wert eine Referenz, darum nennt man die auch Referenz-Variable.

Dafür muß man das aber auch wissen!

Wissen sollte man das, wird ja oft genug allenortens vorgebetet. Gehört sozusagen zum OOP-Basiswissen.

Zitat:

Zitat von p80286 (Beitrag 1316155)

Immer wieder beliebt ist doch auch

Delphi-Quellcode:

  A1 : array[0..5] of word;
  A2 : array of word;
  pWrd : word;

begin
  setlength(A2,6);
  pwrd:=@A1;
  pwrd^:=5;
  pwrd:=@A2;
  pwrd^:=5;
end;

Un nun kommt die Frage "warum steht in A1[0] 5 und in A2[0] nicht?
Das sind doch beides Arrays?"

Gut wir wissen, daß ein dyn.Array etwas anderes ist als ein statisches, aber einem unvoreingenommenen Leser erschließt sich das eben nicht auf den ersten Blick.

Habe mal wegen diesem Codeschnipsel gefragt:

Zitat:

Computer sagt: Nein.

Sprich, das wird noch nicht einmal kompiliert.

Das hier schon

Delphi-Quellcode:

var
  a1   : array [ 0 .. 5 ] of word;
  a2   : array of word;
  LWord: Pword;
begin
  SetLength( a2, 6 );
  LWord  := @a1[ 0 ];
  LWord^ := 5;
  Assert( a1[0] = 5 );
  LWord  := @a2[ 0 ];
  LWord^ := 5;
  Assert( a2[0] = 5 );
end;

Und was soll ich sagen ... so wie es jeder unvoreingenommene Leser erwarten würde, alles im grünen Bereich.

[implementation]

Zitat:

Zitat von Stevie (Beitrag 1316132)

"Dafür gibts ja Format", sagt jetzt jemand. Jup, und dann lokalisier doch mal nen String, der da lautet "Der %s %s wohnt in %s" ohne den Kontext zu kennen (vor allem wenn dann noch Sprachen dazu kommen, bei denen die Grammatik anders funktioniert. Ein String, der da lautet "Der {vorname} {nachname} wohnt in {ort}" ist dann wohl unmisverständlich (klar, der übersetzer muss nun nur noch wissen, dass die Dinger, die zwischen {} stehen nicht übersetzt werden, weil das Variablen namen sind. :)

Hihi, dass damit die Übersetzung auf einmal leichter wäre ist ein Fehlschluss. Das mag in Deutsch und Englisch so klappen, aber man muss sich bei sowas im Hinterkopf behalten, dass es genügend Sprachen gibt, in denen du den Ort nicht einfach so per Format reinsetzen kannst, sondern ihn deklinieren musst :wink:
Man macht sich das schnell ein bisschen zu einfach, und ein Großteil der Programmierer auf der Welt denkt da recht anglozentrisch, und auch im Deutschen wird ja wirklich wenig dekliniert. Gibt es für <Ort> nur eine feste Auswahl, geht es ja auch noch, hinterlegt der Übersetzer eben mehrere Versionen davon - aber dann kommt der Fall, wo <Ort> eine Nutzereingabe ist.

Also, spielen wir das mal durch. Du fragst in einem Formular u.A. nach dem Wohnort einer Person, und bildest daraus einfache Sätze. Maria gibt Helsinki an, und als zukünftigen Wohnort Kuopio.

Zitat:

Maria wohnt in Helsinki.
Maria zieht nächste Woche von Helsinki nach Kuopio.

Klappt doch, oder?

Zitat:

Maria lives in Helsinki.
Next week Maria moves from Helsinki to Kuopio.

Na wer sagt's denn?

Zitat:

Maria asuu Helsingissä.
Ensi viikolla Maria muutaa Helsingistä Kuopioon.

Uppsi :oops:

Also bitte hört auf, euch einzureden, Stringformatierung würde eure Übersetzungsprobleme lösen. Es tut wirklich sehr weh. Lokalisierung ist ein ziemlich f#ck$ng schweres Thema, bei dem einfache Formatierung und Interpolation aber schlichtweg kaum was wert sind.