Prüfen, ob ein Objekt existiert

[B.Hauser]

Binderverzeichnisse haben keine Signatur!

In Binder-Verzeichnissen sind Module oder Service-Programme hinterlegt.

Zur Kompilierungszeit bzw. während des Binder-Schritts werden die Binder-Verzeichnisse duchsucht, ob in den darin gelisteten Objekten die aufgerufenen Prozeduren hinterlegt sind. Wenn ja wird da entsprechende Modul oder die Signatur des Service-Programms in da zu bindende Objekt übernommen.

Mit Binder-Sprache ist es auch möglich mehrere Signaturen für das gleiche Service-Programm zu verwalten, in dem die zuvor exportierten Prozeduren als *PRV-Eintrag in der Binder-Quelle bleiben.
Da das Service-Programm damit sowohl die alte als auch die neue Signatur hat, gibt es auch beim Aufruf von Programmen und Service-Programmen in denen noch die alte Signatur gebunden ist, keine Signatur-Verletzung.

Birgitta

[BenderD]

... eine alte hessische Weisheit sagt:"an de knebscher spiele solle nur de exberrde". Was ich schon für einen Mist über Binder Language gelesen habe, und was ich für einen Unfug gesehen habe, bringt mich dazu Binder Language nur da einzusetzen, wo es erforderlich ist, nämlich bei der Entwicklung von shared Libries, die in fremdem Umgebungen eingesetzt werden - und das machen nur wenige. Für dei Masse von Halb-Experten ist der Recompile halt sicherer (BTW .Net und Java Werkzeuge kompilieren und deployen immer ein ganzes Projekt, da gibt es überhaupt keinen Einzelcompile) und bei Design lastigem Vorgehen - das ich dringendst empfehle - sind Signaturänderungen seltene Ausnahme. Wer ständig Signaturänderungen hat, der hat ernsthafte Mängel im Design!!!

D*B

[Fuerchau]

Das das BNDDIR keine Signatur hat, ist mir auch klar.
Beim Erstellen eines Serviceprogrammes mit Bindarylanguage zwingt mich niemand eine neue Signatur zu vergeben.
Bei vernünftiger Anwendung werden neue Prozeduren immer am Ende hinzugefügt.
Alte Programmaufrufe bleiben erhalten und erzwingen eben keinen Rebind.
Natürlich darf ich die Parameter einer Prozedur nie ändern, aber das galt ja schon immer für OPM-Schnittstellen, ist also überhaupt nichts neues.
Wenn ich mich daran halte, benötige ich nie eine neue Signatur. Auch der Schwachsinn mit *PRV gehört eigentlich verboten.
Die Beibehaltung der Reihenfolge ist zwingend erforderlich, da zur Laufzeit nicht mehr per Name sondern per relativer Nr. in der Liste aufgerufen wird. Eine Parameterprüfung erfolgt nicht!
Erweiterungen kann ich mit *OMMITED-Parametern (am Ende) ggf. durchführen was ich aber besser unterlasse. In .NET/Java/C++ definiere ich überladene Prozeduren mit diversen Parametern, ähnlich wie es ja SQL nun auch kann.
Dies kann ich dann sogar verwenden um eine bestehende Prozedur mit den alten Aufrufen zu belassen und im Inhalt nun die neue Prozedur mit dem/den zusätzlichen Parametern und den Defaults aufzurufen.
Bei der OPM-Programmierung hat man ja eigentlich das selbe getan, warum also nicht auch bei Serviceprogrammen?
Was anderes mache ich mit Überladungen ja nun in anderen Sprachen auch nicht.

Bei .NET wird natürlich ein Projekt kompiliert, aber ein Projekt besteht aus einer Anwendung oder einer DLL.
Zur Laufzeit wird die Version der DLL gebunden, was ich aber durch Manifeste vereinfachen kann.
So kann ich die DLL's separat entwickeln und testen, Versions-Nr'n hochzählen usw.
Allerdings führt .NET und Java eben zur Laufzeit Prüfungen über Aufrufschnittstellen (Namen und Parametertypisierungen) durch um Fehler zu minimieren.

Schlechtes Design gibt es eben überall, so dass es auch dabei knallen kann.

[AG1965_2]

Es hat jeder irgendwo recht. Es kommt auf die (eigene?) Umgebung an.
Wenn man ein riesiges System zu betreuen hat, das nahezu keine Wartungsfenster hat, tue ich mir mit riesigen Deployments schwer, schlicht, weil die Zeit fehlt. Da kommt einem - im designtechnischen Notfall - *PRV durchaus zupass und selbst vergebene Kennungen sind sowieso normal.
Wer damit kein Problem hat, eine kleine Applikation hat, oder es ganz einfach haben will, kann genauso wie in anderen Welten vorgehen und einfach immer alles erstellen, egal, ob es nun notwendig ist oder nicht.
Das Schöne ist, dass uns das System i Beides bietet.