Erste Sprachbeispiele
updated
Ich will nur erst einmal die Informationen loswerden.
Erklären werde ich alles über ein späteres Update.
Ich dachte mir, es wäre einmal interessant, einen kleinen Einblick in den bisherhigen Sprachaufbau zu geben.
Fangen wir am besten mit dem Klassen-Aufbau an:
Wie zu erkennen ist, ist zur Zeit echte Mehrfachvererbung vorgesehen.
Wie in an C++ angelehnten Sprachen üblich, ist der eigentliche Quelltext in der Klassendefinition mit eingeschlossen.
Ein Problem, das mir bei Java aufgefallen ist, ist, dass Methoden und Variablen im ganzen Klassen-Block verstreut sein können. Da versteckt sich mitunter eine private Methode unter einem Haufen public Methoden oder vice versa.
Um den ein bisschen entgegenzuwirken und den Quelltext aufzuräumen, gibt es Sektionen - für jede Sichtbarkeitsebene (private, protected und public) jeweils eine. Jedoch mit einem Unterschied: den Bezeichnungen.
Was ist denn der Unterschied zwischen private und protected?
Warum sollte ich das eine hierfür und das andere dafür benutzen?
Um ein bisschen Licht ins Dunkel zu bringen, werden neue Bezeichner für diese Sichtbarkeits-Ebenen benutzt, die dem ganzen (hoffentlich) mehr Klarheit verschaffen. In Chest wird es daher folgende Ebenen geben:
Desweiteren ist jede Sektion noch einmal in 2 Unter-Sektionen aufgeteilt: variables und methods. Es dürfte klar sein, dass Variablen in dem einen Block und Methoden (inkl. deren Quelltext) in dem anderen Block definiert werden.
Class-Definition:
Nun kommen wir einmal zur Variablen-Deklaration:
Dieser ist eigentlich relativ einfach. Da Chest eine "sprechende" Programmiersprache sein soll, wird eine Variable auch einfach als ein "<Name> als <Typ>" definiert.
Variable-Definition:
Auch bei der Definition von Methoden gibt es keine Zauberei:
Jedoch gibt es im Gegensatz zu anderen Sprachen keine "einfachen" Rückgabewerte mehr. Stattdessen definiert man für jede Methode eine List von Rückgabewerten. Dadurch spart man sich Parameter-Strukturen, die in anderen Sprachen Gang und Gebe sind (z.B. var-Parameter in Pascal, Reference-Übergaben wie in C, C++, etc.). Stattdessen definiert man einfach weitere Rückgabewerte.
Nun mag man sich fragen: "Wie soll man mehrere Rückgabewerte auslesen können?"
Schließlich will man eine Methode ja nicht mehrfach aufrufen, nur um dann jeweils einen weiteren Rückgabewert auszulesen, wie z.b. in:
Um solche Probleme zu umgehen, wird ein besonderer Trick angewendet, den ich schon länger mit mir umhertrage: "Warum betrachtet man Methoden nicht wie Klassen?"
Diese Idee ist ja teilweise schon im Umlauf - z.B. ist in Java der Konstruktur einer Klasse einfach deren Name (der Rückgabe der Methode ist eine Klasse mit dem Namen der Methode). So etwas kann man doch auch für normale Methoden einführen - eben um die Rückgabewerte darin zu speichern. Um dies zu erreichen, muss also für jede Methode ein eigener (dynamischer) Typ im Hintergrund generiert werden. Dadurch sind dann soetwas möglich:
Nun aber noch zu ein Paar weiteren Dingen:
Neben normalen Methoden wird es noch abstrakte Methoden (is abstract) geben. Dabei handelt es sich lediglich um die Definition einer Methode ohne deren Implementierung. Dadurch ist es möglich, eine Form von Interfaces zu schreiben.
Des weiteren wurde ja bereits angesprochen, dass Chest die Möglichkeit der Mehrfachvererbung erhalten soll. Nun ist jedoch die Frage, was sein soll, wenn zwei Superklassen einer Klasse Methoden besitzen, die genau gleich definiert sind (Name und Parameterliste stimmen überein), sodass die Methoden nicht als überladen definiert sein können.
Für diesen Fall gibt es das Renaming (is <ClassName>.<MethodName>). Durch dieses wird es möglich, Methoden einer Superklasse in einem Nachkommen unter einem neuen Namen anzubieten. Diese Möglichkeit ist natürlich genau dann nützlich, wenn man Namenskonflikte bei verschiedenen Elternklassen auflösen muss.
Method-Definition:
Zum Schluss gibt es noch einmal ein kleines Quelltext-Beispiel.
Calling a Method
So, damit wäre dieses größere Update auch schon zu Ende.
Ich hoffe, der Einblick in den derzeitigen Sprachaufbau war für euch interessant.
Man beachte aber bitte, dass Dinge wie "println()" und das Type-Casting nur als Platzhalter zu verstehen sind. Hier ging es erst einmal um die im Text näher beschriebenen Sprachfeatures.
Über Änderungen halte ich euch natürlich auf dem Laufenden!
Bis demnächst...
Wirsing
Ich will nur erst einmal die Informationen loswerden.
Erklären werde ich alles über ein späteres Update.
Ich dachte mir, es wäre einmal interessant, einen kleinen Einblick in den bisherhigen Sprachaufbau zu geben.
Fangen wir am besten mit dem Klassen-Aufbau an:
Wie zu erkennen ist, ist zur Zeit echte Mehrfachvererbung vorgesehen.
Wie in an C++ angelehnten Sprachen üblich, ist der eigentliche Quelltext in der Klassendefinition mit eingeschlossen.
Ein Problem, das mir bei Java aufgefallen ist, ist, dass Methoden und Variablen im ganzen Klassen-Block verstreut sein können. Da versteckt sich mitunter eine private Methode unter einem Haufen public Methoden oder vice versa.
Um den ein bisschen entgegenzuwirken und den Quelltext aufzuräumen, gibt es Sektionen - für jede Sichtbarkeitsebene (private, protected und public) jeweils eine. Jedoch mit einem Unterschied: den Bezeichnungen.
Was ist denn der Unterschied zwischen private und protected?
Warum sollte ich das eine hierfür und das andere dafür benutzen?
Um ein bisschen Licht ins Dunkel zu bringen, werden neue Bezeichner für diese Sichtbarkeits-Ebenen benutzt, die dem ganzen (hoffentlich) mehr Klarheit verschaffen. In Chest wird es daher folgende Ebenen geben:
- implementation (= private)
hier definierte Variablen und Methoden sind nur der Klassen-Implementation zugänglich - inheritor (= protected)
hier definierte Variablen und Methoden sind nur der Klassen-Implementation und deren Erben (engl. inheritors) zugänglich - public
hier definierte Variablen und Methoden sind jedem zugänglich
Desweiteren ist jede Sektion noch einmal in 2 Unter-Sektionen aufgeteilt: variables und methods. Es dürfte klar sein, dass Variablen in dem einen Block und Methoden (inkl. deren Quelltext) in dem anderen Block definiert werden.
Class-Definition:
<ClassName> inherits <ClassName> [, <ClassName>]
//... contains variables and methods that
//... are available to this class
implementation
variables
//... some variables
variables;
methods
//... some methods
methods;
implementation;
//... contains variables and methods that
//... are available to this class and
//... to inheriting classes
inheritor
variables
//... some variables
variables;
methods
//... some methods
methods;
inheritor;
//... contains variables and methods that
//... are available to all classes
public
variables
//... some variables
variables;
methods
//... some methods
methods;
public;
<ClassName>;
Nun kommen wir einmal zur Variablen-Deklaration:
Dieser ist eigentlich relativ einfach. Da Chest eine "sprechende" Programmiersprache sein soll, wird eine Variable auch einfach als ein "<Name> als <Typ>" definiert.
Variable-Definition:
<Name> as <Type>;
Auch bei der Definition von Methoden gibt es keine Zauberei:
Jedoch gibt es im Gegensatz zu anderen Sprachen keine "einfachen" Rückgabewerte mehr. Stattdessen definiert man für jede Methode eine List von Rückgabewerten. Dadurch spart man sich Parameter-Strukturen, die in anderen Sprachen Gang und Gebe sind (z.B. var-Parameter in Pascal, Reference-Übergaben wie in C, C++, etc.). Stattdessen definiert man einfach weitere Rückgabewerte.
Nun mag man sich fragen: "Wie soll man mehrere Rückgabewerte auslesen können?"
Schließlich will man eine Methode ja nicht mehrfach aufrufen, nur um dann jeweils einen weiteren Rückgabewert auszulesen, wie z.b. in:
begin
println(Calculate(5, 5).Add);
println(Calculate(5, 5).Divide);
println(Calculate(5, 5).Multiply);
end;
Um solche Probleme zu umgehen, wird ein besonderer Trick angewendet, den ich schon länger mit mir umhertrage: "Warum betrachtet man Methoden nicht wie Klassen?"
Diese Idee ist ja teilweise schon im Umlauf - z.B. ist in Java der Konstruktur einer Klasse einfach deren Name (der Rückgabe der Methode ist eine Klasse mit dem Namen der Methode). So etwas kann man doch auch für normale Methoden einführen - eben um die Rückgabewerte darin zu speichern. Um dies zu erreichen, muss also für jede Methode ein eigener (dynamischer) Typ im Hintergrund generiert werden. Dadurch sind dann soetwas möglich:
variables
MyVariable as Calculate;
variables;
begin
MyVariable = Calculate(5, 5);
println(MyVariable.Add);
println(MyVariable.Divide);
println(MyVariable.Multiply);
end;
Nun aber noch zu ein Paar weiteren Dingen:
Neben normalen Methoden wird es noch abstrakte Methoden (is abstract) geben. Dabei handelt es sich lediglich um die Definition einer Methode ohne deren Implementierung. Dadurch ist es möglich, eine Form von Interfaces zu schreiben.
Des weiteren wurde ja bereits angesprochen, dass Chest die Möglichkeit der Mehrfachvererbung erhalten soll. Nun ist jedoch die Frage, was sein soll, wenn zwei Superklassen einer Klasse Methoden besitzen, die genau gleich definiert sind (Name und Parameterliste stimmen überein), sodass die Methoden nicht als überladen definiert sein können.
Für diesen Fall gibt es das Renaming (is <ClassName>.<MethodName>). Durch dieses wird es möglich, Methoden einer Superklasse in einem Nachkommen unter einem neuen Namen anzubieten. Diese Möglichkeit ist natürlich genau dann nützlich, wenn man Namenskonflikte bei verschiedenen Elternklassen auflösen muss.
Method-Definition:
<MethodName> get ([<Name> as <Type>;])
set ([<Name> as <Type>;])
is abstract;
<MethodName> get ([<Name> as <Type>;])
set ([<Name> as <Type>;])
is <ClassName>.<MethodName>;
<MethodName> get ([<Name> as <Type>;])
set ([<Name> as <Type>;])
variables
//... some variables
variables;
begin
//... some sourcecode
end;
Zum Schluss gibt es noch einmal ein kleines Quelltext-Beispiel.
Calling a Method
//...
returnLongWord get (Value as LongInt;)
set (Result as LongWord;)
begin
Result = LongWord:Value;
// cast Value to a LongWord (not yet sure)
end;
//...
variables
myValueA as retunLongWord;
myValueB as LongWord;
variables;
begin
myValueA = returnLongWord(5);
println(myValueA.Result);
myValueB = returnLongWord(5).Result;
println(myValueB);
println(returnLongWord(5).Result);
end;
//...
So, damit wäre dieses größere Update auch schon zu Ende.
Ich hoffe, der Einblick in den derzeitigen Sprachaufbau war für euch interessant.
Man beachte aber bitte, dass Dinge wie "println()" und das Type-Casting nur als Platzhalter zu verstehen sind. Hier ging es erst einmal um die im Text näher beschriebenen Sprachfeatures.
Über Änderungen halte ich euch natürlich auf dem Laufenden!
Bis demnächst...
Wirsing

0 Kommentare:
Kommentar veröffentlichen
Links zu diesem Post:
Link erstellen
<< Startseite