Vereinfachte Methodenparameter-Deklarationen

Im Streben nach effizienter Kodierung konfigurieren 4D Entwickler häufig Kompilierungspfad-Einstellungen, um Syntax- und Typisierungsprüfungen zu verbessern und so Fehler bei der Codeausführung im Kompilierungsmodus zu minimieren. Schauen wir uns an, wie #DECLARE Methodenprototypen Zeit und Codesicherheit gewinnen.

Normalerweise mussten 4D Entwickler bei Kompilierungspfad-Einstellungen wie ‚Prozess- und Interprozess-Variablen sind typisiert‘ oder ‚Alle Variablen sind typisiert‘ Methodenparameter ein zweites Mal in einer ‚compiler_‘-Methode deklarieren.

Mit der Einführung von 4D v20 R4 gehört dieser zusätzliche Schritt jedoch der Vergangenheit an.Parameter, die in einem #DECLARE Methodenprototypdeklariert werden , erfordern keine redundante Deklaration in einer ‚compiler_‘ Methode mehr.

Die Deklaration von Methodenparametern in einem #DECLARE Prototyp bietet nun die gleichen Vorteile wie bei Klassenfunktionen. Damit ist die bisherige Deklaration von Methodenparametern veraltet.

Ein Vorteil dieser Verbesserung ist, dass bestehender Code davon unberührt bleibt. In ‚Compiler_‘-Methoden deklarierte Parameter werden weiterhin erkannt. Wenn ein Parameter in einer ‚compiler_‘-Methode und einem Methodenprototyp deklariert ist, wird kein Fehler ausgelöst, solange ihre Typen übereinstimmen. Allerdings führt eine Abweichung der Typen nun zu einem Fehler, was zu einer verbesserten Codesicherheit beiträgt.

Da in Prototypen deklarierte Methodenparameter keine zweite Deklaration in einer ‚compiler_‘-Methode mehr erfordern, fügt die Aktion ‚generate typing‘ im Kompilierdialog ausschließlich außerhalb des Prototyps deklarierte Parameter hinzu.

Um einen reibungslosen Übergang zur Verwendung von Methodenprototypen zu ermöglichen, führt das neueste Update Warnungen in zwei Szenarien ein:

  • Wenn Parameter sowohl im Körper einer Methode als auch in ihrem Prototyp deklariert werden.
  • Wenn eine Methode mit mehr Parametern aufgerufen wird, als in ihrem Prototyp deklariert sind.

Diese Funktion spart Ihnen Zeit und verbessert die Codequalität, indem sie Laufzeitfehler im kompilierten Modus proaktiv verhindert.

Avatar
- Product Owner - Damien Fuzeau ist seit Februar 2019 Mitglied des 4D Produktteams. Als Product Owner ist er für das Schreiben von User Stories zuständig, die er dann in funktionale Spezifikationen umsetzt. Zu seinen Aufgaben gehört es auch, dafür zu sorgen, dass die gelieferten Funktionsimplementierungen den Anforderungen der Kunden entsprechen. Damien hat an der Universität von Nantes einen Abschluss in Softwaretechnik gemacht. Er verbrachte mehr als 23 Jahre in seinem früheren Unternehmen, zunächst als Entwickler (er entdeckte 4D im Jahr 1997) und später als technischer Leiter und Softwarearchitekt. Dieses Unternehmen ist ein 4D OEM Partner und hat 4D basierte Geschäftssoftware für Tausende von Usern auf Hunderten von Servern eingesetzt. Damien ist also mit der Entwicklung und dem Einsatz von 4D in einem mehrsprachigen Kontext vertraut.