input-Feld mit parent-Element umhüllen?

[Orlok]

Hallo Rolf

const {parentElement} = p;

Ich glaube nicht, dass ich mich in diesem Leben an solcherlei codetechnische Kryptographie noch gewöhnen werde. "Destrukturierende Deklaration" - allein der Begriff bricht mir Zunge und Finger.

Letztlich ist es doch nur ein Lesbarkeitsschleier (auch Syntaxzucker genannt) für dies hier:

const parentElement = p.parentElement;

und die ungezuckerte Version empfinde ich als deutlich genießbarer.

Mir kommt diese Version wiederum unnötig umständlich vor.

Du hast natürlich recht, wenn du darauf hinweist, dass die Deklaration mit explizitem Zugriff auf das Feld den Ablauf bei der Auswertung des Ausdrucks deutlicher herausstellt. In dieser Hinsicht ist die Syntax für die Destrukturierung sicherlich abstrakter. Das ist allerdings nicht die einzige Perspektive, aus der man dieses sprachliche Konstrukt betrachten kann.

Die beiden Ausdrücke sind eigentlich ein schönes Beispiel für die synaktischen Ausprägungen der unterschiedlichen Ansätze der deklarativen und der imperativen Programmierung. Während bei der Destrukturierung der logische Zusammenhang veranschaulicht wird, folgt die Syntax mit explizitem Feldzugriff den einzelnen Schritten des Algorithmus. Einmal betone ich als Autor, was ich erreichen möchte und einmal, wie ich es zu erreichen gedenke.

Die Syntax für die Destrukturierung ist dabei nicht willkürlich gewählt, sondern als syntaktisches Gegenstück zur Definition von Objekten in Literalschreibweise gedacht, bei der es sich ebenfalls um eine deklarative Syntax handelt. Auch bei der Definition von Objekten habe ich die Wahl, stattdessen eine imperative Syntax zu verwenden:

// Erzeuge ein Objekt und füge Eigenschaften hinzu!

const film = new Object();

film.name = 'Nosferatu – Phantom der Nacht';
film.year = 1979;
film.director = 'Werner Herzog';

Hier kann man wieder argumentieren, dass im Vergleich zur Definition mit einem Objektliteral der Ablauf des Programms durch die Syntax besser verdeutlicht wird. Aus meiner Sicht ist diese Version jedoch viel zu umständlich, da ich analog zur Wiederholung des Eigenschaftsnamens im Eingangsbeispiel hier den Namen des Objektes für jede Eigenschaftsdefinition wiederholen muss.

Da ich für die Definition von Objekten die Literalschreibweise bevorzuge, ist es nur konsequent, dass ich auch beim Zugriff eine deklarative Syntax verwenden möchte. Der Bezug wird deutlich, wenn man die Erzeugung und die Destrukturierung eines Objekts direkt gegenüberstellt:

// Strukturierung

const film = { name: 'Aguirre, der Zorn Gottes',
               year: 1972,
               director: 'Werner Herzog' };


// Destrukturierung

const { name,
        year,
        director } = film;

Die beiden Sprachkonstrukte sind symmetrisch. Mit derselben Syntax, mit der ich eine Eigenschaft definiert habe, greife ich auch auf sie zu. Wenn man diese Vorstellung zu Grunde legt, dann sollte die Syntax für die Destrukturierung nicht mehr kryptisch erscheinen.

Wie schnell man sich an diese Syntax gewöhnt und ob man sich überhaupt an sie gewöhnen will, hängt sicher auch davon ab, ob man bereits Erfahrungen mit deklarativer Programmierung gesammelt hat und ob einem dieses Paradigma zusagt oder nicht, zumal Destrukturierung und das syntaktisch ähnliche Pattern Matching hier unverzichtbare Grundbausteine der Sprachen darstellen.

-- Beispiel für Destrukturierung in Haskell

data Film = Film String Int
     deriving (Eq, Show)

(Film name year) = Film "Fitzcarraldo" 1982

Destrukturierung und Pattern Matching sind semantisch übrigens nicht dasselbe. Zwar kann Pattern Matching dazu verwendet werden, Werte aus zusammengesetzten Datentypen an Bezeichner zu binden, aber der wesentliche Zweck ist hier die Fallunterscheidung. Ein Wert wird mit mehreren Mustern verglichen und bei Übereinstimmung der mit dem Muster assoziierte Ausdruck ausgewertet.

Viele Grüße,

Orlok