Diskussion:Unterprogramm
Lizenzhinweis
Diesen Hinweis bitte nicht entfernen oder archivieren und immer an erster Stelle auf dieser Diskussionsseite belassen.
Die Artikel Unterprogramm und Prozedur (Programmierung) haben sich thematisch überschnitten. Daher wurden aus dem Artikel Prozedur (Programmierung) einige Textpassagen übernommen und in Unterprogramm eingefügt.
- hier findet sich der Artikel Prozedur (Programmierung) zum Zeitpunkt der Übernahme
- hier findet sich die zusammengefasste Versionsgeschichte des Artikels Prozedur (Programmierung).
S.K. (Diskussion) 23:12, 20. Okt. 2013 (CEST)
Wirkung => Seiteneffekt
Ich habe Wirkung wieder durch Seiteneffekt ersetzt, weil das mE der meist verwendete Fachausdruck ist. Ausserdem schreiben Engländer meist ohne Bindestrich. Hubi. Die Fachsprache kann man nun mal nicht ändern. 08:01, 8. Apr 2004 (CEST)
Unterschied zwischen Parameter und Argument
Was ist der Unterschied zwischen Parameter und Argument? Ich habe schon häufiger gehört, dass der Parameter bei der Definition des Unterprogramms gebraucht wird, während die Argumente die Werte sind, die beim Aufruf tatsächlich übergeben werden. Falls es bei diesen Begriffen einen Konsens gibt, sollte der im Artikel auftauchen. --RolandIllig 00:22, 20. Mai 2004 (CEST)
- Kein Unterschied. Prozeduren haben Parameter, bei Funktionen spricht man eher von Argument. Da das bis auf das Result fast dasselbe ist, werden die Begriffe oft synonym verwendet. Wirths Programming in Modula-2 verwendet nur den Begriff Parameter, das ADA Reference Manual verwendet auch Parameter, aber das Wort Argument taucht bei Pragma-Definitionen auf. Bei der Definition von Unterprogrammen sprechen die Manuale von formalen Parametern, beim Aufruf dann von aktuellen Parametern. Wenn ich sin(x) aufrufe, nenne ich x das Argument, sowohl beim Aufruf, als auch bei der Berechnung z.B. als Tschebyscheff-Polynom innerhalb der Bibliotheksfunktion. Damit sind sowohl formale als auch aktuelle Parameter Argumente. --Hubi 07:03, 20. Mai 2004 (CEST)
Signatur
Signatur einer Funktion ist doch nur der Name + Parameter aber nicht der Rückgabewert!? -- Jtb 00:02, 20. Jan 2005 (CET)
- Ich denke, das kommt ganz auf die Programmiersprache an. Ich würde sogar weitergehen und behaupten, dass es Sprachen gibt, die nur den Funktionsnamen als Signatur benutzen (was z.B. dann auch einen Overload unmöglich macht). Insofern sollten Parameter und Rückgabewert nur als potentielle Signatur-Teile angesehen werden, abhängig von der jeweils betrachteten Sprache. Werde den Text noch entsprechend ändern. --Kasper4711 17:59, 29. Aug 2005 (CEST)
Signaturen
Habe den Teil über Signaturen überarbeitet. K.A., ob das kleine Beispiel in diesem Artikel bleiben kann, da es ja eigentlich eher zu Überladen gehört. --Kasper4711 20:09, 29. Aug 2005 (CEST)
Ich habe einen Kommentar in Diskussion:Funktion_(Programmierung) geschrieben, mit Bezug auf diesen Artikel. --HartmutS 00:46, 12. Feb 2006 (CET)
Überarbeitung
Ich habe gerade nicht alles lesen können, aber in großen Teilen des Artikels fehlen Umlaute (v.a. ü's). Ich kann es jedoch selbst im Moment nicht stemmen, den Artikel durchweg zu korrigieren. -- R. Buchholz 00:03, 17. Mär 2006 (CET)
- Stimmt, habe noch einige Üs usw. korrigiert. Das ist passiert, weil ich bei Übergabe über Zwischenablage zwischen Windows und Linux nicht aufgepasst habe, Thema UTF8 und ISO...(Windows). Der Überarbeitungshinweis ist aus diesem Grunde also wieder weg.
- Der Artikel ist übrigens vollkommen überarbeitet, obige Diskussionsanmerkungen insgesamt damit hinfällig bzw. berücksichtigt. Mich würde mal interessieren, was es für fachliche Meinungen dazu gibt. Habe vergessen mich anzumelden, HartmutS hat geändert.
- PS: Nochmals vielen Dank an diejenigen, die vorher schon die blöden Üs korrigiert haben, hab mir eben die Historie angeschaut. Ich hoffe, jetzt sind wirklich keine Probleme mehr drin. Nunmehr eingeloggt: --HartmutS 20:54, 4. Apr 2006 (CEST)
Grausamer Stil!
Was ein Jargon hier. "casten" und "hintenrum doch in die Daten schreiben". Für eine Enzyklopädie find ich dat schon büsken stark - spielt ja keine Rolle, wenn ich unter Kollegen so rede. Aber Umgangssprache und Jargon hat in WP nun mal nix zu suchen. Es heißt schließlich Enzyklopädie und nicht Enzyklopädie. ;-) Ja, also der Stil ist wirklich grauenhaft, ich setz mal ein "tone"-Template wenn ich das richtige erwische. Zeit wird's. -andy 92.229.164.237 15:24, 18. Dez. 2008 (CET)
- Der komplette Artikel bedarf einer Überarbeitung. Gegenwärtig wirkt das Gebilde, wie ein Flickenteppich. --Stefan Schultz 22:19, 28. Dez. 2008 (CET)
- Also mal langsam. Die Stelle mit casten und hintenrum ist nicht gut, OK, leider ist sie auch fachlich falsch. final in Java wirkt nicht wie const auf den Zeiger sondern wie const auf die Variable selbst, also type* const name. Das sollte korrigiert werden, habe ich daher sofort ausgeführt. Ansonsten steht im Artikel viele und tiefgehende Infos. Den Stil empfinde ich im Ganzen OK. --HartmutS 21:23, 11. Apr. 2009 (CEST)
Auch aus meiner Sicht ist der Inhalt des Artikels miserabel: Vor allem werden Aussagen als absolut hingestellt, die nur für bestimmte Fälle gelten (Programmiersprachen, Betriebssysteme etc.). Allgemeingültige sollte von umgebungsspezifischen Aussagen getrennt sein. Die Beispiele sollten schon in der Überschrift zeigen, für welche Umgebungen sie gültig sind. Außerdem halte ich sie in einer Enzyklopädie für unangebracht und für VIEL zu detailliert: Sowas interessiert doch keinen Leser, der etwas über Unterprogramme lesen will.--VÖRBY 20:47, 15. Jun. 2011 (CEST)
- Da HIER kein Feedeback einging, gehe ich davon aus, dass meine Aussagen zum Detaillierungsgrad Zustimmung finden. Wenn das so bleibt, werde ich in den nächsten Tagen einen drastischen Rückbau vornehmen, vor allem einen Großteil der ausschweifenden Codebeispiele löschen. --VÖRBY 20:29, 4. Jul. 2011 (CEST)
Nach dem Einfügen eines zusätzlichen UPRO-Beispiels (kürzlich) habe ich heute lediglich den Abschnitt 'Gründe ...' nach vorne verschoben und einige Ergänzungen vorgenommen. In den m.E. überbreiten, kaum allgemeingültigen Codebeispielen habe ich den angekündigten 'Rückbau' unterlassen; aus meiner Sicht wär's das nun gewesen. --VÖRBY 19:28, 19. Jul. 2011 (CEST)
Also, ich bin froh dass der Rückbau unterblieben ist. Generell freue ich mich über Wikipedia-Artikel, die in einem kurzen Überblick das Wesentlichste zum Stichwort sagen (wie ein klassisches Lexikon). Dann kann man entscheiden, ob man weiterlesen möchte. Wieviel man lesen möchte, kann man dann selbst entscheiden, wobei eine gute Gliederung hilft. Informationshaltige Artikel mit entsprechenden Querverweisen sind mir dabei sehr gelegen. Schätze, diese Meinung teilen andere auch. Das Problem bei anderen Artikeln der Wikipedia ist oft, dass der gleiche Sachverhalt unter verschiedenen Stichworten mehrfach dargestellt wird. Daher möchte ich für folgenden Stil plädieren: Einige Artikel sehr ausführlich, andere Artikel müssen eigenständig da sein damit das Stichwort gefunden und kurz geklärt wird. Dann sollte es aber den großen Querverweis zu dem ausführlichen Artikel geben, diese Artikel also kurz.--HartmutS 23:13, 6. Jan. 2012 (CET)
Keine Wirkung?
Ob das Unterprogramm/die Funktion eine Wirkung besitzt oder nicht, hängt nun wirklich nicht von der Verwendung des Rückgabewerts ab. (nicht signierter Beitrag von 83.135.114.111 (Diskussion) 09:47, 8. Aug. 2010 (CEST))
War auch nicht so gemeint, ich habe das etwas ausführlicher geschrieben. --HartmutS 23:03, 6. Jan. 2012 (CET)
Welcher Compiler?
Im Abschnitt "Umsetzung auf Maschinenebene" steht bezogen auf die Funktion parabel: der erzeugte Assembler-Code. Von welchem Compiler wird denn dieser Code erzeugt? Das sollte hier erwähnt werden. -- UKoch 18:35, 21. Nov. 2011 (CET)
Habe ich zum Artikel hinzugesetzt (MS Visual Studio 6) --HartmutS 23:04, 6. Jan. 2012 (CET)
Datenbereiche
Die Anmerkung Wird auch als Heap bezeichnet im Abschnitt Übergabe der Parameter/Argumente über den Stack ist falsch oder unzureichend. Nur ein Teil des Datenbereiches ist der Heap. Insbesondere in C für embedded Programmierung wird sehr oft mit statischen Daten gearbeitet, die nicht im Heap allokiert werden. Der Datenspeicher ist grundsätzlich in vier Bereiche aufgeteilt, die oft bestimmten Speichersegementen zugeordnet sind:
- statische schreibbare Daten
- statische read-only Daten, in C werden const -definierte Daten dort eingeordnet (In C++ oft nicht, da die Programmiersprache const Initialisierung zur Laufzeit viel stärker unterstützt).
- Heap
- Stack
Diese detaillierten Ausführungen würden aber den Artikel hier sprengen. Bin dafür die oben genannte Anmerkung einfach zu streichen. --HartmutS 23:32, 6. Jan. 2012 (CET)
Module sind keine Unterprogramme
Nur ein paar Belege für meine Änderung/Aussage, dass Module keine Unterprogramme sind:
„Neben dem Hauptprogramm und den externen Unterprogrammen ist die dritte Art von Programmeinheiten das Modul (module). Auch Module können Unterprogramme enthalten, die dann Modul-Unterprogramme (module subprogramms) heissen [...]“
„Moduldefinitionen in VBA
Ein Modul kann zusammengehörige Unterprogramme zusammenfassen. Die Namen von Unterprogrammen eines Moduls brauchen nur innerhalb des Moduls eindeutig zu sein.“
Dabei ist die Aussage, dass Module Unterprogramme enthalten können, aber keine Unterprogramme sind. Mehr Beispiele finden sich mit etwas googlen ausreichend... :-)
Danke und Gruss, --S.K. (Diskussion) 20:14, 21. Okt. 2013 (CEST)
- Noch mal "an der Quelle" nachgeschaut:
“Below are several partial system descriptions called modularizations. In this context "module" is considered to be a responsibility assignment rather than a subprogram.”
- --S.K. (Diskussion) 22:01, 21. Okt. 2013 (CEST)
Meine Meinung: Dieses Lemma beschreibt den Begriff 'Unterprogramm' allgemein, also implementierungs- und technologieneutral. Unterschiedliche Epochen, Betriebssysteme, Programmiersprache etc. haben unterschiedliche Formen und Begrifflichkeiten für solche Konstrukte hervorgebracht. Deshalb sollte der Leser (auch die OMA) hier alle Bezeichnungen wiederfinden, die in diesem gesamten Kontext für 'Unterprogramm' oder in ähnlicher Bedeutung benutzt werden. Deine Belege argumentieren aus der Sicht bestimmter Technologien; wenn man zB [1] interpretiert, ist ein 'Modul' auch etwas, das der Definition in der Einleitung des Lemmas entspricht. Im Sprachgebrauch getätigte Aussagen wie "Routine, Unterprogramm, Funktion ... aufrufen" sind ohne Weiteres auch mit dem Ausdruck 'Modul' identisch möglich. Außerdem: Genauso wie für 'Modul' könnte man für Funktion, Methode etc. diskutieren, ob das 'Unterprogramme' sind. Mit dem Ergebnis, dass es viele unterschiedliche Varianten gibt. Sicher könnte man sogar weitere Ausdrücke ergänzen - wie Section (zB in Cobol wie Unterprogramme behandelt).
Ich würde deshalb zumindest 'Modul' wieder aufnehmen, den bisherigen Abschnitt aber wie folgt umformulieren - um klarzustellen, dass die Ausdrücke fallweise nicht exakt dasselbe meinen:
- Im Sprachgebrauch und je nach benutzter Entwicklungstechnologie werden für den Begriff 'Unterprogramm' auch andere Ausdrücke verwendet (und umgekehrt), zum Beispiel Prozedur, Funktion, Methode, Modul,Routine/Subroutine, Operation etc.. Die verschiedenen Bezeichnungen sind teils historisch entstanden, teils im Umfeld verschiedener Programmiersprachen, und können sich auch in der Bedeutung in Details unterscheiden.
Ich denke aber, es lohnt sich nicht, hier hohen Disk-Aufwand zu betreiben; es geht wohl darum, ob man eine engere oder eine weitere Sicht HIER dokumentieren will. Entscheiden sollten vielleicht 'Dritte Meinungen'. Gruß von --VÖRBY (Diskussion) 09:44, 22. Okt. 2013 (CEST)
„Meine Meinung: Dieses Lemma beschreibt den Begriff 'Unterprogramm' allgemein, also implementierungs- und technologieneutral. Unterschiedliche Epochen, Betriebssysteme, Programmiersprache etc. haben unterschiedliche Formen und Begrifflichkeiten für solche Konstrukte hervorgebracht. Deshalb sollte der Leser (auch die OMA) hier alle Bezeichnungen wiederfinden, die in diesem gesamten Kontext für 'Unterprogramm' oder in ähnlicher Bedeutung benutzt werden.“
- Da stimme ich dir voll zu bis auf den letzten Teilsatz (oder in ähnlicher Bedeutung), der geht für mich zu weit. Der Artikel sollte m.E. den Begriff „Unterprogramm“ so genau wie möglich definieren. Das dabei weitgehend synonyme Begriffe erwähnt werden sollen, klar. Darunter fallen für mich die übrigen Beispiele (Prozedur, Funktion, Methode, Routine/Subroutine, Operation). Der entscheidende Unterschied zu Modul ist, dass all diese Begriffe für Konstrukte verwendet werden, die genau einen Einsprungpunkt haben, eine - hoffentlich sinnvolle ;-) - Aufgabe erledigen und dann zur Stelle des Aufrufs zurückkehren.
- Ein Modul dagegen kann man auch aufrufen, da stimme ich dir zu, aber es ist wie in den obigen Beispielen gezeigt, eben nicht auf diesen einen Einsprungpunkt beschränkt. Das Modul besteht typischerweise aus mehreren (hoffentlich nach Parnas sinnvoll zusammengestellten) "Unterprogrammen", die in Summe eine Abstraktion/eine Menge von Designentscheiden kapseln. Es ist daher konzeptuell etwas ganz anderes, als ein Unterprogramm.
- Die Diskussion zeigt m.E. auch noch eine Schwäche in der einleitenden Definition auf. Bei Bedarf kann man sie auch als für Module gültig ansehen, aber dann gilt sie auch für Programmbibliothek und ähnliches. Von daher fände ich es zielführender, wenn man die Trennschärfe der Definition erhöhen könnte, statt den Begriff durch die Aufnahme von Modulen als Beispiel zu verwässern.
- --S.K. (Diskussion) 23:01, 22. Okt. 2013 (CEST)
- PS: Bei deinem Link sehe ich nicht, dass man daraus Modul==Unterprogramm ableiten kann. Dort steht z.B. „Moduln enthalten Spezifikationen, Definitionen abgeleiteter Typen oder Anweisungen zur Speicherverwaltung. Weiterhin können auch Prozedur-Bibliotheken mit zugehörigen Schnittstellen-Informationen enthalten sein.“ und „MODULE comm […] CONTAINS SUBROUTINE […]“.
- PPS: Meine Meinung: Funktionen sind Unterprogramme (solche, die einen Wert zurückgeben), Methoden sind es auch (solche, die einem Objekt - z.B. bei JavaScript - oder einer Klasse - z.B. bei Java - zugeordnet sind), Prozeduren sind es im Normalfall auch (typischerweise ohne dass sie einen Wert zurückgeben), Routine/Subroutine und Operation sind Synonyme zu Unterprogramm. (Das wird nicht immer streng genau so verwendet, aber Tendenz geht nach meiner Erfahrung dahin).
- Noch eine Bemerkung zu "das Modul abc aufrufen": Das steht ja verkürzend für "das Unterprogramm xyz im Modul abc aufrufen". (totum pro parte). --S.K. (Diskussion) 09:14, 23. Okt. 2013 (CEST)
- Guten Morgen und danke für die ausführliche Antwort. Meine Meinung (nochmal) ist, dass es viele Varianten dieses Konstrukts 'Unterprogramm' gibt, vor allem auch in unterschiedlichen Entwicklungsumgebungen - wo sie ggf. auch mit unterschiedlichen Ausdrücken benutzt werden. Die Sichtweise 'Modul ENTHÄLT Unterprogramm(e)' ist nicht die einzig mögliche. So nennt man zB in MS Access Prozeduren synonym 'Module'. In "Access 2002 programmieren" heißt diesbezüglich zB das Kapitel 6.1.1. "Eigenständige Module programmieren". Darin beginnt der Text mit "Um eine neuen Prozedur zu erstellen, klicken Sie ... auf die Schaltfläche Module". Und weiter "Sie können neue Module oder Klassenmodule auch im Editor anlegen". Wir haben hier also ganz klar eine Synonymverwendung. Und in all diesen Fällen gibt es Einsprung- und Exit-Stellen, das 'Modul' ist nicht nur ein Container für n UP's - so wie das zB iZ mit Programmbibliotheken der Fall sein mag.
- Die Definition auf bestimmte Technologien hin einzuengen, halte ich nicht für zielführend. Sie soll die ein Unterprogramm im Allgemeinen "bestimmenden Kriterien" beschreiben. Weiter im Text kann man dann auf Implementierungsunterschiede (und auch Synonyme oder Näherungsbegriffe) eingehen - was ja bereits in der Einleitung auch schon der Fall ist.
- Fazit: 'Modul' und vielleicht auch andere Ausdrücke sollten an fraglicher Stelle wieder aufgenommen werden. Ich habe meinen Vorschlag dazu oben nochmal angepasst. Grüße von --VÖRBY (Diskussion) 09:34, 23. Okt. 2013 (CEST)
- Hast Du mir einen Link, dass ich den Kontext sehen kann? Weil das, was ich zu Access finde, bestätigt nur meine Sicht:
„Zutreffend für: Access 2003 […]
[…] Indem Sie Ihre Datenbank durch das Einbeziehen von Microsoft Visual Basic-Prozeduren erweitern, können Sie Einfluss darauf nehmen, wie die Tabellen, Formulare, Berichte und Abfragen in der Datenbank zusammenarbeiten. Es gibt mehrere Arten von Prozeduren. Sie können eine Ereignisprozedur erstellen, indem Sie einem Ereignis in einem Formular oder Bericht Code hinzufügen. Sie können auch eigene Funktionen oder Sub-Prozeduren in Standardmodulen oder in Klassenmodulen (zu denen Formularmodule und Berichtsmodule gehören) erstellen.“
- Ich vermute, dass man erst ein Modul erstellen muss/soll, bevor man die Prozedur erstellen kann, sprich das Modul ist die Hülle, in die ein Unterprogramm eingefügt werden kann.
- Von daher fehlt mir immer noch eine Verwendung, die (ausserhalb von eventuell sprachlicher Verkürzung) Modul und Unterprogramm synonym behandelt.
- Es geht mir auch nicht darum, Technologien auszuschliessen, aber wir sollten fachlich korrekt sein. Und da bin ich immer noch der Überzeugung, dass ein Modul fachlich/inhaltlich nicht das gleiche ist, wie ein Unterprogramm. Und bisher habe ich kein Beleg für eine gegenteilige Verwendung gesehen.
- Danke und Gruss, --S.K. (Diskussion) 16:10, 23. Okt. 2013 (CEST)
Hallo! Es steht außer Zweifel, dass ein Modul i.S. von Modul (Software), d.h. als Software-Artefakt, nicht gleich Unterprogramm ist. So scheint das auch bei Access zu sein - du hast da wohl Recht.
Mit dem Zusatz soll aber darauf hingewiesen werden, dass der Ausdruck 'Modul' AUCH rein sprachlich und i.S. von Baustein, Teilkomponente (siehe Modularität) alternativ zu 'UP' benutzt wird. So scheint das auch in meinem Access-Buch zu sein. Aus den ersten der ca. 41.000 in Google gefundenen Ergebnisse lässt sich DIESE Art von Modul/UP-Nennung/Bedeutung z.B. bei den folgenden Quellen nachvollziehen:
- Psion http://www.psion-user-club.at/m_opl_04.html: "denn einen Teil der Module (synonym: Prozeduren, Unterprogramme, Programmteil, Programm-Modul) werden wir wiederverwenden."
- Zeiner http://www.zeiner.at/informatik/scripten/CEinfuehrung.pdf: "In der Terminologie des Programmentwurfs bezeichnet man ein Unterprogramm oder Teilprogramm auch als Modul." Hier wird auch gleich die zweite Definition mitgeliefert - also zwei Bedeutungen und eine enge Sprachbeziehung. Auch in Kap 6.1 wird 'Modularisierung' als Aufteilen in mehrere ... Unterprogramme beschrieben, später 'Unterprogrammtechnik' genannt.
- http://www11.in.tum.de/dokument.php?id_dokument=429 S.31: "Binden und Laden von Unterprogrammen" - eigentlich wären da Module gemeint, hier liegt also eine Synonym-Anwendung vor.
- econstor: [2] S19: "... in n Unterprogramme (Module) zerlegt ist ..." Auch der weitere Text verwendet die Ausdrücke als Synonym.
Vielleicht wäre es irgendwann auch mal sinnvoll, die Unterschiede der einzelnen Ausdrücke zu erläutern; denn Synonyme sind es ja wohl oft nicht, sonst wären ja eigene Lemmata nicht gerechtfertigt. ZB ist Prozedur ja höchstens 'eine Variante' von UP (als allgemeiner Begriff). Insofern kann man wohl auch keine glasharte, technologisch basierte Definition für UP hier unterbringen. Die Links habe ich modifiziert - weil der WP-Spamfilter 'gemotzt' hatte. Weiteren Aufwand will ich nicht betreiben. Grüße von --VÖRBY (Diskussion) 20:44, 24. Okt. 2013 (CEST); ergänzt: --VÖRBY (Diskussion) 16:33, 25. Okt. 2013 (CEST)
- Sorry, das es mit der Antwort etwas gedauert hat, war etwas stärker im RL beschäftigt...
- Bezüglich der Belege bin ich nicht begeistert, aber ich kann dein Argument zum Thema Modularität nachvollziehen. Unterprogramme können ein poor-man's-Mechanismus/Hilfsmittel sein, um Modularität herzustellen, sofern keine explizite Unterstützung vorhanden ist, um das volle Konzept im Sinne von Modul (Software) zu implementieren (insofern bin ich auch mit deiner Formulierung „Modul […] als Software-Artefakt“ nicht ganz glücklich. Module sehe ich als Konzept, dass seinen Niederschlag in Artefakten finden kann, dem muss aber nicht so sein). Ich würde Modul und Unterprogramm heute (spätestens seit Parnas) trotzdem nicht als Synonyme behandeln. Frage ist dann, wie wir das im Artikel gut beschreiben können. Ich denke, ich mach mal einen Vorschlag im Text, du kannst bei Nichtgefallen dann einfach anpassen. Wenn es größerer Diskrepanzen gibt, diskutieren wir gerne hier weiter. Hoffe, das ist so für dich in Ordnung.
- Und ja, ich denke, wir sollten die etwas abweichenden Bedeutungen von Prozedur etc. direkt ansprechen. Ich schaue mal, was ich machen kann.
- --S.K. (Diskussion) 17:37, 3. Nov. 2013 (CET)
- So, habe mich mal daran versucht…. Feedback sehr willkommen. --S.K. (Diskussion) 18:38, 3. Nov. 2013 (CET)
- Hallo, ich denke mein Warten hat sich gelohnt. Deine Anpassungen kann ich voll akzeptieren. "Mein Modul ;-)" kommt ja jetzt wieder vor und es wird klar, dass damit etwas anderes gemeint ist als das Modul in technischem Sinn; ein Synonym ist das insofern nicht. Und das gilt ja auch für andere Bezeichnungen. Die Unterschiede in den Begriffen zu erläutern, halte ich auch für sinnvoll, aber kurz sollte es bleiben.
- Meine Quellen waren nur zufällige Fundstellen für die Verwendung von Modul i.S. Modularität/Komponente/Baustein. Grüße von --VÖRBY (Diskussion) 18:47, 3. Nov. 2013 (CET)
- Prima, dann haben wir ja eine Lösung gefunden, die für beide passt. Dann hat es sich die längere Diskussion also gelohnt. Gerne wieder. :-) Dann noch einen schönen Abend. --S.K. (Diskussion) 20:24, 3. Nov. 2013 (CET)
- Zu deinem Kommentar "hat nichts mit 'heutig' zu tun, sondern ist eine andere Bedeutung": Den Begriff "Modul" gab es in der Software schon vor Parnas, z.B. steht in der Einleitung von seinem Paper:
- Prima, dann haben wir ja eine Lösung gefunden, die für beide passt. Dann hat es sich die längere Diskussion also gelohnt. Gerne wieder. :-) Dann noch einen schönen Abend. --S.K. (Diskussion) 20:24, 3. Nov. 2013 (CET)
“A lucid statement of the philosophy of modular programming can be found in a 1970 textbook on the design of system programs by Gouthier and Pont [1, I0.23], which we quote below:1
- A well-defined segmentation of the project effort ensures system modularity. Each task forms a separate, distinct program module. At implementation time each module and its inputs and outputs are well-defined, there is no confusion in the intended interface with other system modules. At checkout time the integrity of the module is tested independently; there are few scheduling problems in synchronizing the completion of several tasks before checkout can begin. Finally, the system is maintained in modular fashion; system errors and deficiencies can be traced to specific system modules, thus limiting the scope of detailed error searching.”
- Von daher hatte ich "heutig" gewählt um von diesen früheren, weniger spezifischen/präzisen Verwendungen abzugrenzen. Das zur Info, ich kann auch ohne "heutig" leben. ;-) --S.K. (Diskussion) 21:09, 4. Nov. 2013 (CET)
Es gibt auch hier - wie in vielen IT-Themen - engere und weitere Definitionen, Synonyme und (oft nur geringfügig) abweichende unterschiedliche Bedeutungen/Begriffe. Das ist auch hier der Fall. Ich meine nicht, dass 'heutige' diese Unterschiedlichkeiten exakt genug bezeichnet, es ist nur ein Aspekt von vielen. Insofern denke ich: Besser draußen lassen. Jedenfalls benutzt auch dein Zitat den Begriff 'Modul' eher i.S. von 'Modularität', weniger i.S. von 'Container, der Code, u.a. auch Unterprogramme) enthalten kann', was ich oben 'Artefakt' genannt hatte und zu dem wir uns einig sind, dass DIES kein UP 'ist'. --VÖRBY (Diskussion) 10:24, 5. Nov. 2013 (CET)
- Es geht weniger um engere und weitere Definitionen, als um neuere und ältere. In dem obigen Zitat ist ein älteres Zitat enthalten, das aus einer Zeit stammt, bevor die Definition von Modul geschärft/weiterentwickelt wurde und die "heutige" Definition von Modul entstand. Dabei geht es primär um Information Hiding, dass ist es was ein Modul ausmacht (ausmachen sollte):
“The second decomposition was made using "information hiding" [4] as a criterion. The modules no longer correspond to steps in the processing. […] Every module in the second decomposition is characterized by its knowledge of a design decision which it hides from all others. Its interface or definition was chosen to reveal as little as possible about its inner workings.”
- Das dieses Prinzip in heutigen Progammiersprachen seinen Niederschlag oftmals in einem Container findet, der die Unterprogramme und Datenstrukturen des Moduls bündelt, ist eine Folge/eine Umsetzung der Definition. Aber am Anfang steht die Definition, die das Information Hiding in den Vordergrund stellt. Das war es, warum ich sagte, mir gefällt dein Bezug auf Artefakt nur begrenzt. --S.K. (Diskussion) 23:26, 6. Nov. 2013 (CET)
- Hallo S.K.: Ich denke, im Wesentlichen sind wir einig: Dass es in der Computertechnik mehrere Bedeutungen des Ausdrucks 'Modul' gibt. Zu 'neuer und älter' oder 'Information hiding': Das sind vielleicht zwei von mehreren Aspekten; aber 'neuer/älter' passt nicht wirklich, denn Module i.S. von Container für Vieles, u.a. auch für UP's gab es schon in frühesten Assemblerzeiten. Lassen wir es jetzt also gut sein!? Aus meiner Sicht sind wir vollkommen 'durch, wir müssen ja hier keine Erbsen zählen. Grüße von --VÖRBY (Diskussion) 10:43, 7. Nov. 2013 (CET)
Im Rahmen der Redundanzdiskussion 25.3.14 habe ich die hier 'erarbeitete' Ansicht, 'Modul' seinicht zwangsläufig mit 'UP' identisch, bei Modul (Software) eingetragen. Die Tatsache, dass Ausdrücke gerade in der IT häufig mehrere Bedeutungen aufweisen, ist auch ein Aspekt dieser Redundanzdisk - der auch bei anderen Lemmas noch einzutragen wäre.
- Unter Methode wird meines Wissens in der Objektorientierung ein Unterprogramm bezeichnet, das einen "this" (oder auch self- oder me-)Pointer besitzt. Eine Unterprogramm, das sich also auf ein Objekt (und nicht auf eine Klasse) bezieht. Da sich Objekte ja auch auf Klassen beziehen, ist das im Hauptartikel beschriebene nicht ganz falsch, doch würde ich eher schreiben:
- Methode
- Unter einer Methode versteht man in objektorientierten Programmiersprachen Unterprogramme welche sich auf ein Objekt beziehen.
Phiki (Diskussion) 16:21, 15. Jan. 2015 (CET)
