Programmiersprachenstile

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Programmiersprachenstile

    Ich befasse mich aktuell mit dem Thema automatisierter Quellcodegenerierung. Da der Quellcode nicht nur in einer Sprache geschrieben sein kann, will ich passende Basisimplementationen entsprechend auslagern und einzelne Paradigmen, zum Beispiel Schlüsselworte, etc. in entsprechende Klassen auslagern. So kann ich zum Beispiel einen Basis-Renderer für die Sprachen Java, PHP, JavaScript, ... erstellen. Da andere Sprachen, wie Pascal oder Perl über eine ganz andere Syntax verfügen, würde ich solche Sprachen gerne zu entsprechenden Obergruppen zusammenfassen. Dies wären momentan einmal die Sprachen im Java- und im Basic-Stil.
    Jetzt die eigentliche Frage: Kennt ihr passende Namen für solche Stilgruppen? Oder kennt ihr vielleicht bessere Zusammenfassungen solcher Gruppen? Da würde ich gerne mal ein paar Ideen und Meinungen hören.
    Es geht dabei ausschließlich um das Look&Feel der Sprache, nicht um Eigenschaften wie Objektorientierung, etc.

  • #2
    Ich hoffe ich habe es richtig verstanden: Du willst Gemeinsamkeiten irgendwelcher Sprachen zusammenfassen. Dazu zählst du Schlüsselwörter wie const und syntaktische Regeln wie "auf function folgt öffnende Klammer".

    Wie bist du auf diesen Ansatz gekommen?
    Hast du dir mal die Grammatiken (EBNF) der Sprachen besorgt?

    Kommentar


    • #3
      Ich hoffe ich habe es richtig verstanden: Du willst Gemeinsamkeiten irgendwelcher Sprachen zusammenfassen.
      Richtig.
      Dazu zählst du Schlüsselwörter wie const und syntaktische Regeln wie "auf function folgt öffnende Klammer".

      Wie bist du auf diesen Ansatz gekommen?
      Hast du dir mal die Grammatiken (EBNF) der Sprachen besorgt?
      Auch richtig. Aber nicht ganz so stumpf. Einzelne Elemente (Klasse, Property, ...) verfügen über eine Reihe Modifikatoren. Der Satz gültiger Werte ist dabei von der Sprache gegeben. Genau wie die möglichen Sichtbarkeiten eines Elementes.

      Genau durch die EBNFs bin ich darauf gekommen.
      Es geht primär um die Generierung von Klassen/Schnittstellen und hier ist die Syntax bei zum Beispiel Java und PHP schon vergleichbar, so dass ich gerne das Erstellen von Klassen/Methodenrümpfen entsprechend solch einem Stil auslagern würde. Der konkrete Rumpf der Methoden wird durch passende Objekte bzw. Ableitung/Dekoration hinzugefügt, das kann glaube ich kaum generisch gehalten werden bzw. wäre zu komplex.

      Falls noch unklar ist, was ich vorhabe, frag einfach

      Kommentar


      • #4
        Dir schwebt etwas in dieser Richtung vor:
        PHP-Code:
        class ClassGenerator {}
        class 
        MethodGenerator {}
        class 
        AccessModifierGenerator {}
        class 
        PublicAccessModifierGenerator {}
        class 
        PrivateAccessModifierGenerator {}
        ...

        class 
        PHPClassGenerator extends ClassGenerator {}
        class 
        PHPMethodGenerator extends MethodGenerator {}

        class 
        JavaClassGenerator extends ClassGenerator {}
        class 
        JavaMethodGenerator extends MethodGenerator {} 
        Das ist jetzt noch kein ordentliches OO-Design sondern soll nur der Veranschaulichung dienen.

        Zur Sache: Die Klassen *AccessModifierGenerator fügen dem generierten Code die Schlüsselwörter public, private usw. hinzu.
        Die Klassen [PHP|Java]*AccessModifierGenerator sind deiner Meinung nach nicht notwendig, weil die Schlüsselwörter in PHP und Java identisch sind.

        Soweit hast du recht und wenn du den Generator wirklich vollständig von Hand weben möchtest, dann mag dieser Ansatz auch gangbar sein.

        Ich würde jedoch einen anderen Ansatz wählen. Ich würde einen Code-Generator-Generator (CGG) schreiben. Der erzeugt aus einer (E)BNF die Klassen, die wiederum Code erzeugen. Gebe ich ihm die (E)BNF von Java, erzeugt er die Klassen JavaClassGenerator, JavaMethodGenerator von oben. Da er immer nur eine (E)BNF verarbeitet, kann er gar keine Gemeinsamkeiten verschiedener Sprachen kennen.
        Der erzeugte Code ist mit Sicherheit umfangreicher als handgestrickter. Aber man muss ihn ja nie manuell bearbeiten, insofern ist das egal. Wenn sich die (E)BNF ändert, wird der CGG einfach nochmal angeworfen.

        Wenn der CGG fertig ist, kann man einen (E)BNF Präprozessor schreiben. Der frisst mehrere (E)BNFs und markiert Gemeinsamkeiten in einer Art, dass der CGG erkennt, dass es sich bei solchen Token um sprachunabhängige oder zumindest sprachenübergreifende Token handelt. Mit diesem Wissen kann der CGG abtrakte Teil-Generatoren (wie PublicAccessModifier) bauen, die in den spezifischen Sprach-Generatoren (wie [PHP|Java]MethodGenerator) verwendet werden.

        Man ahnt schon, dass so ein Präprozessor ziemlich komplex wird. Und wozu? Der einzige Effekt wäre, dass man am Ende weniger Klassen hat, weil sich der PHP- und Java-Generator welche teilen. Zur Laufzeit, also wenn man PHP oder Java generiert, hat das gar keinen Effekt. Da man die Code-Generatoren niemals manuell ändert, spielt Wartbarkeit auch keine Rolle. Also wozu?

        Ich fasse zusammen: Wenn du alles von Hand baust, kannst du fürs OO-Design die (E)BNFs übereinander legen und abstrahieren. Wenn du nur einen Teil der Sprachen umsetzen willst, z.B. Klassen- und Methodenrümpfe, dann ist Handarbeit auch der geeignetere Weg.
        Wenn du mehr als Coderümpfe generieren willst, solltest du über einen CGG nachdenken. Und dann kann es dir egal sein, ob der CGG besonders schlanke CGs erzeugt.
        Zuletzt geändert von onemorenerd; 07.05.2009, 10:53.

        Kommentar


        • #5
          In die Richtung deines OO-Gedanken geht mein Generator, richtig. Über einen GG habe ich auch schon nachgedacht, aber wie du im letzten Abschnitt schon sagst, begrenzt sich das ganze vorerst auf Klassen-/Methodengerüste.
          Generell ist das Einlesen einer EBNF und das Erstellen eines Generators sicher der weitsichtigere Weg, ist für diesen Zweck aber erstmal zu komplex. Sprich, erstmal wird es jetzt eine handgestrickte Lösung geben. Der GG kommt dann vielleicht ja in einer späteren Version dazu. Ist aber eine super Idee
          Um damit noch einmal auf die Ausgangsfrage zurück zu kommen. Ich werde jetzt vorerst die beiden Stile C++/Java und Basic implementieren und diese entsprechend der konkreten Sprache erweitern.

          Vielen Dank für die ausführliche Antwort.

          Kommentar


          • #6
            Cool. Würde mich freuen, wenn du uns das fertige OO-Design dann mal präsentierst. Gern auch schon in der Entwurfsphase, damit wir gemeinsam (also hoffentlich nicht nur wir beide sondern alle Mitlesenden) was lernen und evtl. Verbesserungen vorschlagen können.
            Das hat mal ein ganz anderes Niveau als das, was hier sonst so aufläuft und würde das Forum sicherlich bereichern.

            Kommentar


            • #7
              Cool. Würde mich freuen, wenn du uns das fertige OO-Design dann mal präsentierst. Gern auch schon in der Entwurfsphase, damit wir gemeinsam (also hoffentlich nicht nur wir beide sondern alle Mitlesenden) was lernen und evtl. Verbesserungen vorschlagen können.
              Das hat mal ein ganz anderes Niveau als das, was hier sonst so aufläuft und würde das Forum sicherlich bereichern.
              Ich werde mal schaun, was ich so herausgeben darf. Aber ich denke, das Klassendiagramm sollte schon drin sein

              Kommentar


              • #8
                Original geschrieben von onemorenerd
                Cool. Würde mich freuen, wenn du uns das fertige OO-Design dann mal präsentierst. Gern auch schon in der Entwurfsphase, damit wir gemeinsam (also hoffentlich nicht nur wir beide sondern alle Mitlesenden) was lernen und evtl. Verbesserungen vorschlagen können.
                Das hat mal ein ganz anderes Niveau als das, was hier sonst so aufläuft und würde das Forum sicherlich bereichern.
                mich würde die herangehensweise an so ein "großes" projekt schon interessieren .. aber das niveau ist extram hoch für meine verhältnisse und würde sehr wahrscheinlich nicht mitkommen um das alles zu kapieren.

                der verschlüsselungs/entschlüsselungs thread hatte mir schon einige probleme bereitet

                dennoch würde ich mich darüber freuen näheres zu sehen und somit mein kenntnisstand zu erweitern.
                Gruß
                Uzu

                private Homepage

                Kommentar

                Lädt...
                X