Diskussion:Duck-Typing

In Go

In Google's Go Implementiert ein Typ implizit ein Interface, sobald er alle Methoden davon Implementiert. Ist das nicht mit Duck-Typing gleich zu setzen? -- 217.110.68.146 13:27, 31. Mär. 2010 (CEST)

Interessante Frage:

• Ist das Python-Beispiel auf Go übertragbar?
• Wie würde es aussehen?
• Lt. en:Comparison of programming languages ist Go statisch und optional explizit typisiert. Was passiert, wenn ich einer Funktion ein Nicht-Duck-Objekt übergebe, aber ein Argument erwartet wird, das das Duck-Interface implementiert?

• Ist der Code kompilierbar?
• Ist er lauffähig?
• Offenbar gibt es keine Fehlerbehandlung mit Exceptions. Was würde also passieren, wenn ein unpassendes Objekt verarbeitet wird?

Da ich davon ausgehe, daß dieses implizit implementierte Interface explizit überprüft wird, würde ich sagen: Nein, es ist kein Duck-Typing (aber eine interessante Idee für statisch typisierte Sprachen, die in diese Richtung geht). --Tobias 20:52, 29. Okt. 2010 (CEST)

Und in C++?

C++ bietet ja etwas ähnliches, das allerdings zur Kompilierzeit als Fehler erkannt wird: Hat man ein Template, so wir dunabhängig von der Klasse darüber gemeckert, dass die Methode nicht existiert:

 template<class QuakClass> string quak(QuakClass duck)
 {
   return duck.quak();
 }

Ruft man nun auf:

 quak(Bird("Gustav"));

ergibt dies einen Fehler.

 quak(Duck("Donald"));

und

 quak(Frosch("Der Frosch"));

dagegen werden akzeptiert. (nicht signierter Beitrag von Chricho (Diskussion | Beiträge) 22:32, 30. Nov. 2008)

Duck Typing in C#

"Essentially, C# is doing a fairly strong form of 'duck typing' here. [...] There are a few places in the C# language where we do this sort of "pattern matching"; we don't care what the exact type is, just so long as the methods we need are available." Quelle: Sign In Fabulous Adventures In Coding - Following the pattern (MSDN Blog von 'Eric Lippert', der mit am Design von C# gearbeitet hat.)

--80.143.245.200 03:33, 26. Mai 2012 (CEST)

Ja, schön; demnach unterstützt C# offensichtlich Duck-Typing.

Das vorliegende C#-Beispiel könnte aber durch ein paar sinnvolle Kommentare entschieden leserlicher werden. In der aktuellen Form trägt es m. E. nichts zur Erklärung des Konzepts bei – zumal mich das Interface IBird mißtrauisch macht (ich beiße mich jetzt nicht durch dieses Beispiel in einer Sprache, um die ich bisher herumgekommen bin). Das Beispiel gehört IMHO entweder so eingedampft, umgearbeitet und kommentiert, daß man es verstehen kann, oder gelöscht. --Tobias (Diskussion) 01:51, 5. Feb. 2014 (CET)

Ich habe gehandelt und das C#-Beispiel nach Duck-Typing/C-Sharp-Beispiel verschoben. Wer sich berufen fühlt, daraus ein anschauliches und nützliches Beispiel zu machen, möge das tun. Ich bin mir aber nicht sicher, daß es sich wirklich um Duck-Typing handelt.

Viel interessanter würde ich allerdings Beispiele aus den anderen erwähnten Sprachen finden (Groovy, PHP und Ruby). --Tobias (Diskussion) 21:31, 27. Feb. 2014 (CET)

„zeitigen“ ungleich „zeigen“

Das Wort „zeigen“ ist groß in Mode; im Grundkurs „Deutsch für Fussballer“ wird es als zweitwichtigstes deutsches Wort (nach „Hurz“, natürlich) jedem eingebimst, der „Leistung zeigen“ soll. Wie bei der angeblichen Abschaffung des Eszetts neigen aber offenbar einige zur Übergeneralisierung und meinen, alles, was irgendwie ähnlich aussieht, müsse in Wirklichkeit „zeigen“ heißen. Aus gegebenem Anlaß also zur Klarstellung:

• Es existiert tatsächlich ein Wort „zeitigen“; es steht in meinem Duden (immerhin „Maßgebend in allen Zweifelsfällen“) und bedeutet „hervorbringen“.
• Ein Ergebnis wird nicht gezeigt (allenfalls vorgezeigt), sondern hervorgebracht, mithin gezeitigt.
• Es mag ja sein, daß das gehobener Wortschatz ist;
• es ist aber keinesfalls unverständlich, sondern erschließt sich unmittelbar aus dem Kontext.
• Es hat noch keinem geschadet, auch im gesetzten Alter (jenseits der Schule) noch etwas dazuzulernen.
• Der Spaß, den Diskussionsbeiträge machen, ist mitunter umgekehrt proportional zur Größe des Anlasses ;-)
• Als derjenige, der einige Sorgfalt in diesen Artikel und das Python-Beispiel investiert hat, lege ich doch etwas Wert darauf, daß er nicht aus blanker Unkenntnis stilistisch verschlimmbessert wird.
• „Fußball“ schreibt man immer noch mit Eszett.

Wer also als nächster „zeitigen“ in „zeigen“ ändert, ohne sich hier geäußert zu haben, wundere sich nicht, wenn seine diesbezügliche Änderung das zeitliche segnet. --Tobias 18:48, 23. Jun. 2009 (CEST)

Da derjenige, der einige Sorgfalt in diesen Artikel und das Python-Beispiel investiert hat, gleich mit einem Revert droht: Was geschieht mit Ergebnissen? Gezeigt werden sie sicherlich nicht – so weit sind wir uns einig. Im gehobenen Wortschatz mag man sie zeitigen können, aber allgemein erscheint mir diese Wortwahl unüblich. Laut Google-Demokratie (die als Beweis nicht zulässig ist – ich weiß …) sind die Fügungen „ein Ergebnis bringen“ und „ein Ergebnis liefern“ je nach Satzzusammenhang etwa dreißig- bis tausendmal häufiger. Wenn wir davon ausgehen, dass „to yield a result“ der übliche Ausdruck im Englischen ist, schlägt LEO „ein Ergebnis bringen“ vor. Was also ist zu tun? (Ich selbst werde mit Sicherheit überhaupt nichts tun.) Wie auch immer: Dass die Formulierung keinesfalls unverständlich sei, sondern sich unmittelbar aus dem Kontext erschließe, ist sicherlich richtig – die meisten Leser werden den kleinen stilistischen Fehlgriff (in diesem Falle nach oben) vermutlich einfach übergehen. (Punkt 6 oben verspricht hier also einen Riesenspaß!) --78.48.144.148 21:38, 14. Dez. 2010 (CET)

Selbstverständlich kenne ich das Wort "zeitigen"; ich hab es gelesen und wollte es direkt ändern in "..würde zu xx führen". Ich empfinde die Verwendung als einen Stilbruch im übrigen Artikel, der außerdem unnötige Schwierigkeiten für den Leser zeitigt (ich habe - in der IT - viele Nicht-Muttersprachler als Kollegen). Ein Gewinn für den Artikel erschließt sich mir allerdings nicht. Nachdem ich jedoch zuförderst diese Diskussion gelesen habe, gewann ich den Eindruck, dass es hier offenbar nicht um Artikelqualität geht, sondern um etwas anderes, vielleicht Erziehung des erwachsenen Lesers oder Selbstdarstellung des Autors, jedenfalls etwas, dessen Beurteilung psychologischer Kriterien bedarf, nicht Kenntnis von Programmierstilen. Daher überlasse ich es dem Autor, sich nach inzwischen fünf Jahren vielleicht doch noch einmal des Artikels anzunehmen. Gruß, --INM (Diskussion) 07:29, 1. Dez. 2014 (CET)

Hab' den gehobenen Ausdruck nun mit Synonym ersetzt.  @xqt 09:03, 1. Dez. 2014 (CET)

Also "hervorbringen" gefällt mir nicht wirklich. Mit "würde zu ... führen" könnte ich mich evtl. anfreunden; ich sehe allerdings keinen echten Grund dafür. Ich kann das Problem mit "zeitigen" nicht erkennen. Dieses eine Wort erschließt sich nun wirklich jedem aus dem Kontext.

Die Einlassung von INM enthält allerdings einige Unverschämtheiten. Ich bin selbst in der IT tätig und stelle fest, daß viele meiner Programmierkollegen zwar meinen, gut Englisch zu können, aber ihre englischen Programmkommentare (wenn sie denn überhaupt mal etwas kommentieren) sind fast schlechter als gar keine, und ihr (muttersprachliches!) Schriftdeutsch ist unwesentlich besser. Ich will hier niemanden erziehen, aber ich stelle fest, daß hier über die Jahre kein einziges entfernt vergleichbares Beispiel in einer anderen Programmiersprache beigesteuert wurde, und würde mich über ein Mindestmaß an Respekt vor meinem Werk - das für mich durchaus aus einem Guß ist - doch freuen. --Tobias (Diskussion) 00:56, 17. Dez. 2014 (CET)

Von mir aus auch "Zum selben Ergebnis führt nachfolgender Code:". Die Sätze sollten nicht auseinandergerissen werden, dazu sind die Code-Schnipsel zu lang. "zeitigen" ist gestelzt, vielleicht auch österreichisch, wir sollten's vermeiden.  @xqt 07:49, 17. Dez. 2014 (CET)

PHP und Duck-Typing?

Ich kenne keine PHP-Version, die Duck-Typing unterstützt! Dynamisch typisiert, ja, aber Duck-Typing: eindeutig nicht. Das ist ganz normales Klassen-Gewurschtel.-- 188.98.75.58 20:34, 13. Apr. 2012 (CEST)

Hierzu habe ich folgendes Beispiel gefunden. Letztlich wird dort, unabhängig von etwaiger Verwandschaft, jeweils die Methode getPath aufgerufen. Sieht aus wie Duck-Typing, oder? --Tobias (Diskussion) 01:25, 5. Feb. 2014 (CET)

Gutes Beispiel, aber es zeigt auch, dass die Definition von Duck-Typing weiter aufgesplittet werden sollte. In PHP wird ein Objekt doch durch eine Klasse beschrieben und nicht durch das Vorhandensein von Methoden. Die Methoden einer Instanz können auch nicht verändert werden. Es kann auch nicht ein Anonymes Objekt erzeugt und mit Methoden ausgestattet werden. Das alles sind Gründe, warum PHP nicht direkt Duck-Typing nach der Definition des Artikels unterstützt, im Gegensatz zum nicht genannten JavaScript, wo all dies geht und so ein Objekt konstruiert werden kann, das nur noch durch seine Methoden klassifizierbar ist. Aber PHP erlaubt es, eine Methode unabhängig davon aufzurufen, ganz gleich zu welcher Klasse das Objekt gehört und gleich welche Signatur diese Methode besitzt. Damit lässt sich Duck-Typing leicht realisieren. Wenn man Duck-Typing nicht so definiert, dass eine Klasse nicht vorhanden sein darf, sondern dass es möglich sein muss, allein anhand der unterstützten Methoden ein Objekt zu klassifizieren, dann gehört auch PHP zu den Sprachen, die Duck-Typing unterstützen.

Dennoch ist es keineswegs für PHP charakteristisch, dass Duck-Typing genutzt wird. Im Gegenteil, sofern Bezeichner typisiert sind, ist Duck-Typing nicht möglich, und seit PHP explizite Typisierung beherrscht, wird dies überwiegend als gute Praxis akzeptiert und auch praktiziert. Ich schlage daher auch vor, PHP aus der Auflistung von Sprachen, für die Duck-Typing charakteristisch ist, zu streichen und z. B. durch JavaScript zu ersetzen. --Janopae (Diskussion) 18:51, 9. Apr. 2020 (CEST)

"Duck-Typing"? Wirklich?

Ich war schon etwas verwirrt, als ich vom englischsprachigen Wikipedia-Artikel auf diesen deutschen Artikel mit der lustigen Überschrift gestoßen bin.

Warum hat man nicht beim entsprechenden Verweis gleich auf die richtig bezeichnete, deutschsprachige, Wikipedia-Seite "Ententest" verwiesen und hier lediglich eine Weiterleitung auf die Wikipediaseite "Ententest" eingefügt? (Das ist, wohlgemerkt, eine rhetorische Frage.)

--My2Cents (Diskussion) 13:05, 16. Jul. 2012 (CEST)

Ich teile ja die Abneigung gegen überflüssige Anglizismen und so Unsäglichkeiten wie „Sale“ statt Sommer-/Winterschlußverkauf usw. Aber was sollen wir mit einer rhetorischen Frage anfangen?

Ich würde mal sagen (ohne mir die Mühe zu machen, das nachzusehen), daß die zwei Artikel unabhängig voneinander entstanden sind und die ursprünglichen Autoren das jeweils andere Schlagwort nicht kannten. Es gibt natürlich Unterschiede - der Duck-Typing-Artikel behandelt objektorientierte Programmierung, der Ententest-Artikel hat einen völlig anderen Schwerpunkt.

Es gibt m. E. zwei Möglichkeiten:

1. In beiden Artikeln sinnvolle Querverweise zum jeweils anderen unterbringen;
2. beide Artikel zusammenführen, was nur unter Ententest ginge. Ich kann mir aber vorstellen, daß das nicht so richtig gut passen würde.

Vorbehaltlich schlagender Argumente für die zweite Variante plädiere ich für die erste. --Tobias (Diskussion) 01:38, 5. Feb. 2014 (CET)

Python-Beispiel: ducks statt birds

Ein wohlmeinender Mitstreiter hatte mein Python-Beispiel dahingehend geändert, daß die Liste ducks in birds umbenannt wurde, und die Schleifenvariable entsprechend bird statt duck. Nach reiflicher Überlegung habe ich das revertiert, und zwar aus folgenden Gründen:

• Es geht letztlich um einen Ententest - ich gehe davon aus, daß meine Objekte Enten sind. Daß Enten außerdem Vögel sind, spielt eher eine Nebenrolle.
• Ich will nicht herausfinden, ob ein konkreter Vogel eine Ente ist; ich gehe davon aus, daß meine Objekte Enten sind. Alles andere ist Fehlerbehandlung.
• Ich finde es so klarer. Ansonsten habe ich mich an die gute Konvention gehalten, Klassennamen groß und Variablennamen klein zu schreiben ...

--Tobias (Diskussion) 02:09, 5. Feb. 2014 (CET)

Revert der Auslassungspunkte

Es geht umseitig nicht um nur persönliche Vorlieben sondern auch und besonders um die in WP:WSIGA genannten Wegweiser. Wir schreiben in ganzen Sätzen. Einen Satz mit Ellipsen zu beginnen ist zumindest schlechter Stil was man doch leicht erkennen kann:

„für das Duck-Typing entscheidend ist, dass wir die Klasse nicht (wie im folgenden Code) explizit überprüfen, sondern lediglich das Vorhandensein der relevanten Methode:“

vs.

„für das Duck-Typing entscheidend ist, dass wir die Klasse nicht (wie im folgenden Code) explizit überprüfen: … sondern lediglich das Vorhandensein der relevanten Methode.“

Was wird denn mit den Auslassungspunkten ausgelassen?  @xqt 07:42, 17. Dez. 2014 (CET)

Code-Beispiel

Heyho,

bevor das in Wikibeef ;-) ausartet, hier mal mein Schlichtungsversuch.

WP:WWNI schreibt in Punkt 9 wörtlich vor:

„Wikipedia ist keine Sammlung von Anleitungen und Ratgebern. Es ist nicht Aufgabe der Wikipedia, zu erklären, wie man (...) eine Software verwendet[.] (...) Mit der Erstellung von Lehrbüchern und anderen Sachbüchern beschäftigt sich das Schwesterprojekt Wikibooks[.]“

Der erste Satz verbietet Formulierungen wie "Wir betrachten..." in der Wikipedia (völlig unabhängig von der Länge), der Rest der von mir zitierten Sätze erklärt, dass Codebeispiele in dieser Form (wenn sie also tatsächlich nur der Veranschaulichung dienen und nicht selbst Artikelgegenstand sind) in Wikibooks gehören. Das ergibt ja durchaus auch Sinn.

Vorschlag zur Güte: Meine Version bleibt erhalten und ich lege einen Wikibooks-Artikel mit dem "gelöschten" Code und einen Querverweis im Artikel an?
-- Tuxman (Diskussion) 14:37, 13. Mai 2016 (CEST)

@Tuxman: Ich verschieb das mal von meiner Diskussionsseite hierhin, weil hier gehört es hin.

Zunächst einmal habe ich keine Aktien in diesem konkreten Code-Beispiel, weil es weder von mir ist noch mir meine (nicht wirklich vorhanden) Python-Kenntnisse erlauben würden sowas zu schreiben (ich fühle mich eher in anderen Sprachen zuhause).

Aber: Wir haben es hier nicht mit einer Anleitung oder einem Ratgeber zu tun , sondern mit einem Beispiel zur Verdeutlichung des Artikelinhalts. Und das halte ich hier (wie in vielen anderen Code-spezifischen Artikeln auch) nach wie vor für sinnvoll. Da es zugegebenermaßen ziemlich lang ist, können wir das Beispiel aber gerne auf die wirklich nötigen Schritte runterkürzen. // Martin K. (Diskussion) 15:41, 13. Mai 2016 (CEST)

Ich halte das Beispiel eben doch für eine Anleitung - das legen Formulierungen wie "Wir betrachten...", die man sonst nur aus Lehrbüchern kennt, deutlich nahe. Im konkreten Fall: Eine Anleitung zu Duck-Typing in Python. (Würde ich ja bevorzugt in einem Python-Programmier-Wikibook unterbringen wollen.)
-- Tuxman (Diskussion) 16:06, 13. Mai 2016 (CEST)

Wie gesagt: Mein Herz hängt nicht an Python. Aber irgendeine Art von Code-Beispiel sollte es geben, dass verdeutlicht, was diese Beschreibung oben im Code ausgedrückt bedeutet. Eben ein Beispiel im Sinne von Artikel illustrieren // Martin K. (Diskussion) 16:11, 13. Mai 2016 (CEST)

Ich mag Python auch nicht besonders, ich habe es nur mal spaßeshalber ausprobiert. (Mir fehlen da Klammern.) -- WP:Artikel illustrieren spricht von Medien, von Multimedia quasi. Quellcode ist damit nicht gemeint. Das würde auch WWNI widersprechen.

Ich würde so weit gehen zu behaupten, dass die allermeisten Codebeispiele in der dt. Wikipedia gemäß den Regeln in Wikibooks und nicht hierher gehören.
Tuxman (Diskussion) 16:16, 13. Mai 2016 (CEST)

Die Code-Beispiele dienen dem Verständnis, um die Beschreibung zu verdeutlichen. Sie sind keine Anleitung; für was auch? Inwiefern WP:Artikel illustrieren hier zutrifft ist ja insofern nicht ausgemacht, als die dort aufgelisteten Medienbeispiele nicht vollständig sind, selbstverständlich gilt aber das dort geschriebene hier analog. Oder muss denn die Code-Beispiele erst per Bildschirmdump erzeugt werden, wo wir doch H:SYH haben?  @xqt 16:48, 13. Mai 2016 (CEST)

(Quetsch) Bitte nichts durcheinanderwerfen: Die Codebeispiele verstoßen gegen den zweiten Teil von WWNI#9, die Formulierungen ("wir betrachten...") gegen den von dir angesprochenen ersten.
-- Tuxman (Diskussion) 21:24, 13. Mai 2016 (CEST)

@Xqt: Ich meinte damit das hier: „Die Einbindung von Medien kann zum Verständnis des Artikeltextes beitragen.“
Letzten Endes ist Code nichts anderes als ein anderes Medium, dass die auf Deutsch im Fließtext des Artikels vermittelten Informationen ergänzt und als Erläuterungsgrundlage dient.
Ansonsten +1 zu dem von Dir geschriebenen.

@Tuxman: Wenn Du generell etwas gegen Code-Beispiele hast, dann sollte man das erstmal in der Wikipedia_Diskussion:Redaktion_Informatik klären. Das ist ja nichts, was nur diesen Artikel betrifft und rigorose Einzelaktionen sind da sicher nicht sinnvoll. // Martin K. (Diskussion) 17:28, 13. Mai 2016 (CEST)

Habe die Red. mal angepingt.
-- Tuxman (Diskussion) 21:22, 13. Mai 2016 (CEST)

Hallo zusammen, ich habe u.A. den Artikel zu R verfasst und mir währenddessen Anregungen bei weiteren Artikeln geholt. Auch Python, zumal ich darin schon programmiert hab. Im Python-Artikel war mit am meisten Code enthalten, auch bei Ruby. In einigen anderen Artikeln quasi nix (etwa Java). Dem Python-Artikel muss man noch zu Gute halten, dass er ausgezeichnet wurde, allerdings ist das schon lange her. Ich selbst habe mich entschieden auch auf Code zu verzichten, weil es eben die Wikibooks gibt um so etwas darzustellen und es dort auch umfassender sowie lehrreicher dargestellt werden kann.

Das ist hier somit mehr Erfahrungsbericht als Regel. Tendenziell würde ich vom Zweck der Enzyklopädie eher dafür plädieren Code-Beispiele rauszunehmen. Code ist insbesondere nur dann gut verständlich, wenn man die Sprache beherrscht - sollte das Voraussetzung zum Lesen eines Artikels sein? Eine Enzyklopädie soll Nachschlagewerk sein und allgemein Informationen bereitstellen. Duck-Typing gehört bei Python sicherlich zu den wichtigeren Eigenschaften - dennoch wäre es möglich, dass versucht würde jede Eigenschaft der Sprache mit einem Code-Beispiel zu veranschaulichen. Aus meiner Sicht würde das den Artikel nicht lesbarer machen.

--BrunosapiJens (Diskussion) 22:58, 13. Mai 2016 (CEST)