HSpecs automatisch in Sourcen einbinden

[Fuerchau]

Klar.
Ich war allerdings nun bei einem Kunden, der grundsätzlich keine Copystrecken verwendet.
Es wäre ihm zu aufwändig, beim Nachlesen in einem Programm immer in die Copystrecken reinschauen zu müssen um zu verstehen was da so abgeht.
Und "Copystrecken" sind daher bei ihm immer wartungsfrei da es keinen Grund gäbe diese jemals zu ändern.
Auch eine Art der Grundsatzentscheidung.

Da würde der RDi-Editor (egal welcher) helfen, wenn er Copy's dynamisch per auf/zuklappen innerhalb der Quelle sichtbar machen könnte.

[Robi]

ja, das wäre ne Hilfe!

Wir sind noch bei SEU, weil unser SEU, durch UserExit Pgmme, das kann!
/Copy separat anzeigen
/copy separat editieren
/copy integirert editieren und beim speichern wieder zurück schreiben

Vor dem aufklappen müßte RDI ein Userexit erlauben in dem man, je nach Projektstand, die Herkunftslib bestimmen kann.

Robi

[andreaspr@aon.at]

Da würde der RDi-Editor (egal welcher) helfen, wenn er Copy's dynamisch per auf/zuklappen innerhalb der Quelle sichtbar machen könnte.

Das Auf/Zuklappen geht zwar nicht, aber mit einen Rechts-Klick auf die /Copy-Zeile kann der RDi die entsprechende Teildatei öffnen. Man braucht also nicht diese extra zu "suchen".
(Es wird die LIBL verwendet.)
In der Gliederungsansicht werden auch jene Variablen angezeigt, die auch in den Copy-Strecken definiert sind.

[BenderD]

Und "Copystrecken" sind daher bei ihm immer wartungsfrei da es keinen Grund gäbe diese jemals zu ändern.

... das hört sich (fast) vernünftig an!!! Es gibt nicht nur keinen Grund zentrale Copystrecken zu ändern, es gibt dutzende Gründe zentrale Copystrecken keinesfalls zu ändern!!! Ungeprüft compilieren öffnet die Büchse der Pandorra, alles zu prüfen erzeugt mehr Aufwand, als man durch die Verwendung von Copystrecken einzusparen zu meinen glaubt.

D*B

[Pikachu]

Das hört sich etwas nach "Vererbung" an ...
Wie ist das bei objektorientierten Programmiersprachen?
Soll man da besser auch keine Methode mehr ändern, die vererbt worden ist?

... das hört sich (fast) vernünftig an!!! Es gibt nicht nur keinen Grund zentrale Copystrecken zu ändern, es gibt dutzende Gründe zentrale Copystrecken keinesfalls zu ändern!!! Ungeprüft compilieren öffnet die Büchse der Pandorra, alles zu prüfen erzeugt mehr Aufwand, als man durch die Verwendung von Copystrecken einzusparen zu meinen glaubt.

[Fuerchau]

Gerade bei Objektorientierung verbietet sich sowas on Natur aus.
Außer in der Entwicklungsphase (da gibts dann Hilfen wie Refactoring um alle Verweise anzupassen) dürfen Methoden und Eigenschaften nicht mehr geändert werden.
Dafür gibt es genug andere Möglichkeiten wie Overloading (Gleicher Name, unterschiedliche Parameter).
Wenn sich der Inhalt einer Methode als grundsätzlich fehlerhaft erweist so lässt sich dies innerhalb natürlich korrigieren. Funktionserweiterungen sind da aber absolut schädlich. Da gibt es besser Direktivien in der Methode wie "depracticated" mit ggf. dem Hinweis auf neue Methoden.

[BenderD]

Das hört sich etwas nach "Vererbung" an ...
Wie ist das bei objektorientierten Programmiersprachen?
Soll man da besser auch keine Methode mehr ändern, die vererbt worden ist?

... das hat mit Vererbung nichts zu tun. Was OO angeht, kann ich da nur für Java sprechen und da gibt es ganz wesentliche Unterschiede, sowohl was die Sprache selber und auch den Compiler angeht.
- der Compiler prüft grundsätzlich alle Referenzen, auch externe auf Projekt-Ebene
- compiliert und deployed wird immer das gesamte Projekt
- für alles, was darüber hinaus sichtbar ist (public) gibt es eine glasklare Konvention, dass sich das aus der äußeren Sicht betrachtet, niemals ändern darf
- Copystrecken und ähnliche Krücken gibt es in Java nicht

Wenn man denn eine Analogie zur globalen Änderung von H Lochkarten ziehen wollte, dann müsste man in Java ein globales AntSkript für das Deployment aller Projekte verwenden, was kein Java Programmierer auch nur in Betracht ziehen würde und dann müsste man dieses globale Erstellungsskript auch noch ändern wollen und dann alles komplett redeployen, für den letzten Java Programmierer, der das versucht hat, hat man den Knast in Alcatraz wieder eröffnet und der sitzt jetzt dort und muss RPG Programme schreiben - lebenslänglich!!!

D*B

[AG1965_2]

Das ist von meiner Vorstellung paradiesischer Arbeitszustände gar nicht so weit weg, Dieter. :-)

[BenderD]

Das ist von meiner Vorstellung paradiesischer Arbeitszustände gar nicht so weit weg, Dieter. :-)

Alcatraz oder geordnete Arbeitsabläufe ohne Huddel?

D*B

[AG1965_2]

Die einsame Insel natürlich. :-)