BA Arbeit

ba-student

Mitglied
Ihr seit meine letzte Hoffnung!
Mein Professor hat mir eine Aufgabe für meine BA Arbeit gestellt und ich habe sie angenommen ohne wirklich darüber Nachzudenken...
Aber worum geht es:
Es geht um SW-Entwicklung/Compilerbau und speziell um die Erweiterung der Programmiersprache TeaJay. (Link zur Seite: https://teajay.org)
Ich soll mir überlegen wie ich typeswitch erweitern kann und wie ich Interfaces aus der Programmiersprache entferne.
Ich weiß leider nur nicht, was das mit dem typeswitch soll und was ich davon habe könnt ihr mir helfen, des Weiteren verstehe ich nicht warum ich Interfaces aus der Sprache entfernen soll. Habt ihr eine Idee?
Ich verstehe nicht, was mein Prof mit dieser Sprache will, die Entwickler melden sich bei mir nicht zurück!
 

ba-student

Mitglied
Also ich habe deinen Rat beherzigt...
Ich habe heute mit meinem Prof gesprochen und er hat mir erstmal gesagt:
Ich soll erst mal verstehen was typeswitch ist, was so ein Konstrukt bringt und was in teajay fehlt!
Interfaces sollen aus der Sprache entfernt werden, dies soll ich seiner Meinung nach begründen.

Aber lassen wir den zweiten Punkt...
Zum ersten:
Das Konstrukt ist doch blödsinn! Es macht für mich keinen Sinn, da ich mit Casten das gleiche hinkriege.
Aber vielleicht habt ihr eine Idee ?
 

mrBrown

Super-Moderator
Mitarbeiter
Zum ersten:
Das Konstrukt ist doch blödsinn! Es macht für mich keinen Sinn, da ich mit Casten das gleiche hinkriege.
Aber vielleicht habt ihr eine Idee ?
Sowas hat doch riesige Vorteile gegenüber einer if-instanceof-cast-kaskade

Java:
if (x instanceof String) {
 String s = (String)x;
 ....
} else if (x instanceof Integer) {
 Integer i = (Integer)x;
 ....
}
vs.
Code:
typeswitch (x) {
  case String s:
    ...
  case Integer i:
    ...
}
 
Zuletzt bearbeitet:

ba-student

Mitglied
Also ihr haltet typeswitch für ein gutes Sprachkonstrukt ?
In der Doku steht
Zitat:
Durch die Verwendung von typeswitch ist die explizite Umwandlung in Fallblöcke nicht nötig und das Anordnen der Reihenfolge von speziell nach allgemein wird vom Compiler übernommen. Sind bei den Falltypen Interfaces vorhanden, so werden diese zuletzt geprüft. Bei den Interfaces wird, wie bei allen Typen auch, vom Speziellsten zum Allgemeinsten hin geprüft. Die Reihenfolge der Prüfung lässt sich durch den Ableitungsbaum leicht ermitteln. Für jeden Falltyp wird die Tiefe des Typs im Ableitungsbaum ermittelt. Dann lassen sich die Fälle anhand ihrer Tiefe absteigend sortieren. Des Weiteren ist der default-Fall nicht optional. Hierdurch muss der Entwickler bedenken, was passieren soll, wenn kein passender Typ gefunden wird. Dies wird oft bei der if-else-Vorgehensweise vergessen. Ein weiterer Vorteil ist, dass der Quelltext durch typeswitch strukturierter wirkt.

Es steht dort weiter, dass mit Feldern nicht umgegangen wird, wäre dass etwas was man bräuchte?
Was haltet ihr davon...
Mein Prof, hat mir gesagt, dass typeswitch ein mächtiges Konstrukt ist nur leider in der Sprache nicht in allen Punkten umgesetzt wurde. Ich verstehe nur nicht was fehlt?
 

ba-student

Mitglied
Lassen wir das Thema mal mit typeswitch, da werde ich mir was überlegen!

Zum anderen Thema Interfaces aus der Sprache entfernen:
Ich habe mir Überlegt folgende Code einfach umzubauen. Der Bereich wo die Interfaces geparst werden rauszuwerfen und dann passt es ja. Die Sprache kann dann keine Interfaces mehr.

Code:
/*
* Type Identifier AnnotationMethodOrConstantRest ; |
* ClassDeclaration |
* InterfaceDeclaration |
* EnumDeclaration |
* AnnotationTypeDeclaration
*/
private AnnotationTypeElementRestNode parseAnnotationTypeElementRest() throws IOException, CompilerException {
Symbol s = this.lexSymbol;
TypeNode type = this.parseType();
if (type != null) {

if (this.accept(Sym.IDENTIFIER)) {
String ident = this.lastTokenText;
AnnotationMethodOrConstantRestNode amcr = this.parseAnnotationMethodOrConstantRest();
if (amcr != null) {
if (this.accept(Sym.SEMICOLON)) {
return new AnnotationTypeElementRestNode(s, type, ident, amcr);
}
throw new CompilerException("Missing ; after annotation method or constante", this.lexSymbol);
}
throw new CompilerException("Missing annotation method or constante after identifier", this.lexSymbol);
}
throw new CompilerException("Missing identifier after type", this.lexSymbol);
}
ClassDeclarationNode classDecl = this.parseClassDeclaration();
if (classDecl != null) {
return new AnnotationTypeElementRestNode(s, classDecl);
}
//Alos das hier weg
InterfaceDeclarationNode interfaceDecl = this.parseInterfaceDeclaration();
if (interfaceDecl != null) {
return new AnnotationTypeElementRestNode(s, interfaceDecl);
}
EnumDeclarationNode enumDecl = this.parseEnumDeclaration();
if (enumDecl != null) {
return new AnnotationTypeElementRestNode(s, enumDecl);
}
AnnotationTypeDeclarationNode atd = this.parseAnnotationTypeDeclaration();
if (atd != null) {
return new AnnotationTypeElementRestNode(s, atd);
}
return null;
}
Was ich mich Frage, dass ist doch zu einfach Gedacht oder ?
 

Ähnliche Java Themen

Neue Themen


Oben