Overload function

[RWarnecke]

Hallo zusammen,

ich sehe gerade den Wald vor lauter Bäumen nicht mehr. Wo mache ich in diesem Beispiel den Fehler ?

Delphi-Quellcode:

THauptklasse = class(TComponent)
private
public
    function Post(const Msg, Link, Image: string): string; overload;
    function Post(const Msg, Link, Image: string; Page: TPage): string; overload;
    function Post(const Msg, Link, Image: string; Group: TGroup): string; overload;
published
end;

{...}

function THauptklasse.Post(const Msg, Link, Image: string): string;
begin
  Post(Msg, Link, Image, nil);  //<<--- Fehler
end;

function THauptklasse.Post(const Msg, Link, Image: string; Page: TPage): string;
begin
  { To do something }
end;

function THauptklasse.Post(const Msg, Link, Image: string; Group: TGroup): string;
begin
  { To do something }
end;

Die beiden Klassen TPage und TGroup sind von TPersistent abgeleitet.

Wenn ich jetzt kompiliere bekomme ich den Fehler:

Zitat:

[dcc32 Error] Testklassen.pas(842): E2251 Ambiguous overloaded call to 'Post'

Nehme ich jetzt eine der beiden Funktionen mit TPage oder TGroup raus ist der Fehler weg.

[Sir Rufo]

Wie soll der Compiler bei

Delphi-Quellcode:

nil

denn auflösen, welche Methode er nehmen soll? :stupid:

PS: Das ist mit Ambiguous gemeint ;)

[RWarnecke]

Ok, leuchtet ein bisschen ein. Nur was müsste ich machen, dass er bei nil oder bei einer TPage-Klasse immer die Funktion mit TPage nimmt und wenn ich beim Aufruf ein TGroup angebe soll er die andere Funktion nehmen ?

Oder kann ich das gar nicht über eine überladene Funktion regeln ? Ich tue mich immer noch schwer damit.

[mkinzler]

Überrgib eine typisierte Konstante

[RWarnecke]

Wie sollen mir hier typisierte Konstanten weiterhelfen ? Könntest Du das bitte ein bisschen ausführlicher erklären.

[himitsu]

Na wenn das typisiert ist, dann weiß der Compiler ja, daß es TPage sein soll. :zwinker:

Oder typisiere das Nil.

Delphi-Quellcode:

Post(Msg, Link, Image, TPage(nil));

Oder deklariere die Überladungen so, daß es keine derartigen Probleme gibt.


Bei TPage nimmt er ja schon TPage, aber NIL passt nunmal auch zu TGroup, also kann man es nirgends sicher zuordnen.

[daywalker9]

Delphi-Quellcode:

Default(TPage)

als Parameter sollte auch gehen in neueren delphi Versionen.

[RWarnecke]

Hallo zusammen,

ich bedanke mich erstmal für die zahlreichen Antworten. Ich glaube so langsam kapiere ich es. Das Thema ist nicht gerade mein Steckenpferd. Die Variante von himitsu kann ich jetzt ohne Fehler kompilieren. Das hilft mir erstmal weiter, Danke.

[himitsu]

Zitat:

Zitat von RWarnecke (Beitrag 1236788)

Die Variante von himitsu kann ich jetzt ohne Fehler kompilieren.

Das ist im Prinzip die selbe Variante, wie von mkinzler beschrieben,
nur eben mit einer impliziten Konstante.

Delphi-Quellcode:

const
  NoPage: TPage = nil;

Post(Msg, Link, Image, NoPage);

Das Default nutze ich eher für das, wo es her kommt, also in einer generischen Methode.
Denn so ist es ein bissl ungewohnt und nicht direkt als 0/nil zu erkennen.

[Furtbichler]

Andere Idee:
Was ist eigentlich so toll an überladenen Funktionen?
Wieso nicht einfach:

Delphi-Quellcode:

THauptklasse = class(TComponent)
private
public
     function Post(const Msg, Link, Image: string): string; overload;
     function PostPage(const Msg, Link, Image: string; Page: TPage): string;
     function PostGroup(const Msg, Link, Image: string; Group: TGroup): string;
published
end;

Ist für mich mindestens genauso verständlich.

[himitsu]

Methoden mit der selben Funktion heißen so auch gleich?

[Furtbichler]

Zitat:

Zitat von himitsu (Beitrag 1236796)

Methoden mit der selben Funktion heißen so auch gleich?

Sie können nicht die selbe Funktion haben, denn die Parameter sind nicht gleich. Sie machen im Wesen das gleiche, daher wird der Name auch ähnlich sein Die eine postet (was eigentlich?), die nächste postet eine Gruppe und die dritte postet eine Page.

Überladene Funktionen sind überflüssig und ein Zugeständnis an die Faulheit der Programmierer (die sie benutzen). Ich verstehe die scheinbare Ästhetik dahinter, aber es ist nicht (imho) 100% clean.

[BUG]

Es mindestens gibt eine Sache, die ohne überladene Funktionen nicht geht: Das nachträgliche Hinzufügen von Spezialisierungen ohne den aufrufenden Code anzufassen.
Adhoc würde ich behaupten, dass in einigen Fällen gut mit dem Visitor-Pattern zusammen geht.

Ein mögliches Problem in dem Code würde ich an einer anderen Stelle vermuten: Warum ruft die Funktion mit den 3 Parametern überhaupt eine der beiden anderen auf? Vielleicht es günstiger, wenn die gemeinsam genutzte Funktionalität in eine einzelne Methode auszulagern, insbesondere wenn sich die Methoden für Group und Page so wenig unterscheiden, das du nicht mal darüber nachgedacht hast, welche von den beiden du aufrufen möchtest.

[himitsu]

OK, man könnte es natürlich auch so machen:

Delphi-Quellcode:

function Post(const Msg, Link, Image: string; PageOrGroup: TObject=nil): string;

Durch die Überladung hat man einmal das CodeInsight, sowie Codevervollständigung als Hilfe, um darübber die möglichen Parameter zu sehen.
OK, das kann man jetzt auch über DocInsight bekommen.

Aber dadurch hat man immernoch die Typprüfung des Compilers und muß nicht erst nachträglich, also zur Laufzeit, den Typ manuell prüfen.



Allerdings hätte ich es hier anders gelöst, da die 2-Parameter-Variante eh nur eine Weiterleitung ist.

Delphi-Quellcode:

    function Post(const Msg, Link, Image: string; Page: TPage=nil): string; overload;
    function Post(const Msg, Link, Image: string; Group: TGroup): string; overload;

Denn so sieht man auch gleich was aufgerufen wird, wenn man da "nichts" übgibt.

[jaenicke]

Zitat:

Zitat von Furtbichler (Beitrag 1236824)

Überladene Funktionen sind überflüssig und ein Zugeständnis an die Faulheit der Programmierer (die sie benutzen).

Mit Faulheit hat das rein gar nichts zu tun. Es macht nur keinen Sinn sich krampfhaft unterschiedliche Namen ausdenken zu müssen und umgekehrt immer die passende zu suchen, wenn die Funktionen im Grunde alle doch das gleiche machen.

Bei überladenen Operatoren sehe ich z.B. auch keinen Sinn da noch zusätzliche Namen hinzuzufügen, damit die nicht alle implicit oder explicit heißen.

[Furtbichler]

Zitat:

Zitat von jaenicke (Beitrag 1236847)

Mit Faulheit hat das rein gar nichts zu tun. Es macht nur keinen Sinn sich krampfhaft unterschiedliche Namen ausdenken zu müssen und umgekehrt immer die passende zu suchen, wenn die Funktionen im Grunde alle doch das gleiche machen.

Genau das meine ich mit 'Faulheit'('Macht keinen Sinn..krampfhaft..zu müssen'), danke für die Erklärung. q.e.d. :mrgreen:

Mit der von mir beschriebenen Nomenklatur ist das im Übrigen nicht 'krampfhaft', sondern intuitiv und nach Schema 'F' (eine sehr wichtige Eigenschaft von Nomenklaturen). Die Methodengruppe wird ein 'Post' machen. Das biete ich für die Parameter 'TGroup' und 'TPage' an. Hmm, wie würden die Methoden dann heißen? Also ich weiß ja nicht, wie locker Du so bist, aber ich verkrampfe hier noch nicht.

Außerdem ist es mir neu, das man in Zeiten des 'Code Proposals' großartig suchen muss, zumal die Namen ja alle untereinanderstehen. Was machst Du denn bei einer überladenen Funktion? Du suchst Dir 'Post' aus und hoffst, das der 4.Parameter passend überladen wurde, nachdem Du die ersten drei eingetippt hast (ich arbeite nicht mehr mit Delphi, bei VS ist das so und nervt). Bei meiner Variante siehst Du das aber *sofort*. So schlecht kann meine Idee dann ja gar nicht sein, oder? ;-)

Ich weiß ja, das es bequem ist und einer gewissen Ästhetik nicht entbehrt, aber es ist eben nicht konsequent durchgezogenes OOP.

Was macht 'PostGroup'? Es wird die 'TGroup' irgendwie konvertieren und 'posten'. Und 'PostPage'? Die wird eine 'TPage' irgendwie konvertieren und auch posten. In jedem Fall machen die Methoden zu viel, nämlich zwei Dinge (Konvertieren + Posten). Ergo sollte man das Konvertieren vom 'Posten' trennen. Im konkreten Fall kann das natürlich intern anders sein, im Wesen wäre das aber vermutlich so.

Ich kenne natürlich Fälle, wo Überladung wirklich praktisch ist: Bei der Arbeit mit Frameworks (riesiger Funktionsumfang, einfach zu verwenden). Aber es ist eben nur praktisch (wogegen wirklich nichts zu sagen ist). Sauber (=Clean Code) ist es in meinen Augen jedenfalls nicht. Aber ob man immer 100% Clean programmieren möchte oder auch mal fünfe grade sein lassen will, muss jeder selbst entscheiden.

[jaenicke]

Zitat:

Zitat von Furtbichler (Beitrag 1236849)

Mit der von mir beschriebenen Nomenklatur ist das im Übrigen nicht 'krampfhaft', sondern intuitiv und nach Schema 'F' (eine sehr wichtige Eigenschaft von Nomenklaturen). Die Methodengruppe wird ein 'Post' machen. Das biete ich für die Parameter 'TGroup' und 'TPage' an. Hmm, wie würden die Methoden dann heißen? Also ich weiß ja nicht, wie locker Du so bist, aber ich verkrampfe hier noch nicht.

Das sieht dann lustig aus, wenn ein Framework ein paar mehr Möglichkeiten hat...

Delphi-Quellcode:

Contents := PostByPostDataFileReturnString(Url, PostDataFileName);
if PostByPostDataStreamSaveInFileReturnSuccess(Url, PostDataStream, ResultFileName) then
  ...

Das nenne ich unsauber.

[Daniel]

Ein gewisses Augenmaß sollte man beim Design seiner Methoden nicht verlieren. Ein bekanntes SDK, welches mit langen, sprechenden Methoden-Namen arbeitet, ist z.B. das von iOS - gerade weil ObjectiveC das Überladen gar nicht vorsieht. Geht alles, und gar nicht mal schlecht.

[Stevie]

Zitat:

Zitat von jaenicke (Beitrag 1236898)

Zitat:

Zitat von Furtbichler (Beitrag 1236849)

Mit der von mir beschriebenen Nomenklatur ist das im Übrigen nicht 'krampfhaft', sondern intuitiv und nach Schema 'F' (eine sehr wichtige Eigenschaft von Nomenklaturen). Die Methodengruppe wird ein 'Post' machen. Das biete ich für die Parameter 'TGroup' und 'TPage' an. Hmm, wie würden die Methoden dann heißen? Also ich weiß ja nicht, wie locker Du so bist, aber ich verkrampfe hier noch nicht.

Das sieht dann lustig aus, wenn ein Framework ein paar mehr Möglichkeiten hat...

Delphi-Quellcode:

Contents := PostByPostDataFileReturnString(Url, PostDataFileName);
if PostByPostDataStreamSaveInFileReturnSuccess(Url, PostDataStream, ResultFileName) then
  ...

Das nenne ich unsauber.

Das Beispiel verfehlt leider die zitierte Aussage.
Du vermischst hier Überladung aufgrund unterschiedlicher ÜbergabeParameter und Methoden, die unterschiedliche Rückgabewerte haben.
Die Methode deutet schon anhand des Namens an, dass sie mehr als eine Sache macht. Und dann nimmst du auch noch das Result in den Namen auf.

Besser:

Delphi-Quellcode:

Contents := PostByFileName(Url, PostDataFileName);
if TryPostByStream(Url, PostDataStream) and SaveToFile(PostDataStream, ResultFileName) then
  ...

oder

Delphi-Quellcode:

Contents := PostByFileName(Url, PostDataFileName);
if SaveToFile(PostDataStream, ResultFileName) then
  if TryPostByFileName(Url, ResultFileName) then
  ...

Ich würd das sauber nennen.

[Caps]

Nun, die Frage ist doch, welche Probleme das Überladen aufwerfen könnte (Verständnisprobleme beim Lesen des Quellcodes/ Ambiguitäten).
Mir ist Überladen ganz angenehm (wegen meiner eigene Faulheit natürlich ;-)). Wenn keine Probleme entstehen, dann ist es halt syntaktischer Zucker.

lg Caps

[Furtbichler]

Zitat:

Zitat von jaenicke (Beitrag 1236898)

Das sieht dann lustig aus...

Na klar. Übertreibe maßlos, werfe noch die Returnwerte dazu, damit das schön plakativ aussieht und stelle Dich zum Schluß hin und schreie: "Ha! Recht gehabt!". Ich frage mich zwar, was das mit meinem Beitrag zu tun hat, aber blöd sieht das schon aus, wenn Du so eine Nomenklatur umsetzt, da hast Du recht. Must halt ein wenig üben, bis das sinnvoll wird.

Zitat:

Zitat von Caps (Beitrag 1236924)

Nun, die Frage ist doch, welche Probleme das Überladen aufwerfen könnte (Verständnisprobleme beim Lesen des Quellcodes/ Ambiguitäten).
Mir ist Überladen ganz angenehm (wegen meiner eigene Faulheit natürlich ;-)). Wenn keine Probleme entstehen, dann ist es halt syntaktischer Zucker.

Jupp.

Ich schlage mich gerade mit einem UI-Framework herum, das quasi eine Methode hat: 'AddControl'. Im Formular soll ein Control hinzugefügt und an eine Property gebunden werden.

Code:

AddValue(property, label);
AddControl(property, label, width);
AddControl(property, control, label, width);
AddControl(property, control, label, size, color);
...
usw. ca 50 Varianten

Unglaublich unübersichtlich, aber eben auch praktisch. Ein Zugeständnis das Autors an -eben- Faulheit.

[JasonDX]

Zitat:

Zitat von Furtbichler (Beitrag 1236947)

Code:

AddValue(property, label);
AddControl(property, label, width);
AddControl(property, control, label, width);
AddControl(property, control, label, size, color);
...
usw. ca 50 Varianten

Unglaublich unübersichtlich, aber eben auch praktisch. Ein Zugeständnis das Autors an -eben- Faulheit.

Wobei, hier finde ich hängt es stark von den Parametern ab, die übergeben werden: Diese sollten namentlich ausreichend Sinn machen dass erkannt wird, welcher Wert übergeben wird. Dann werden zusätzliche Informationen als die zentrale Aufgabe der Methode in ihrem Namen überflüssig weil redundant. Das würde dann bei deinem Beispiel zu

Code:

addControl(property, control, label, size, color)

führen. Hingegen für 50 Varianten 50 unterschiedliche, sinnvolle Namen zu herzuleiten stelle ich mir unübersichtlicher vor. Wie würde bei deinem Beispiel guter Vorschlag aussehen?

[RWarnecke]

Wow, ich habe gar nicht gewusst, dass man das Thema so auseinander nehmen kann. Bei mir war es so, dass die THauptklasse schon da war und ich die Funktion mit TGroup nur noch hinzugefügt habe. Desweiteren unterscheiden sich die Funktionen mit TPage und TGroup nur in zwei bis drei Zeilen. Deshalb erschien es mir nur klar, dass ich für TGroup eine Overload function mache.

[Furtbichler]

Das werden hier nun mal immer Grundsatzdiskussionen.

[JamesTKirk]

Zitat:

Zitat von Daniel (Beitrag 1236903)

Ein gewisses Augenmaß sollte man beim Design seiner Methoden nicht verlieren. Ein bekanntes SDK, welches mit langen, sprechenden Methoden-Namen arbeitet, ist z.B. das von iOS - gerade weil ObjectiveC das Überladen gar nicht vorsieht. Geht alles, und gar nicht mal schlecht.

Und die WinAPI braucht sich da auch nicht verstecken, man denke da nur an

Delphi-Quellcode:

ConvertSecurityDescriptorToStringSecurityDescriptor

und Co :mrgreen:

Gruß,
Sven

[mkinzler]

Zitat:

Zitat von Furtbichler (Beitrag 1236970)

Das werden hier nun mal immer Grundsatzdiskussionen.

Bei denen sich komischerweise immer die selben Mitglieder beteiligen. :stupid:

[Furtbichler]

Zitat:

Zitat von JamesTKirk (Beitrag 1237004)

Und die WinAPI braucht sich da auch nicht verstecken, man denke da nur an

Delphi-Quellcode:

ConvertSecurityDescriptorToStringSecurityDescriptor

und Co :mrgreen:

Es ist wohl ein riesen Unterschied, ob ich eine Methode vollständig korrekt benenne, oder Nomenklaturdadaismus à la 'Jänickes Satirekabinett' (Damit ist nur die Überzeichnung von Sebastians Antwort gemeint) veranstalte. Was wäre Dir denn lieber?
'CnvScDsc2StrScDsc'?

Zitat:

Zitat von JasonDX (Beitrag 1236951)

Hingegen für 50 Varianten 50 unterschiedliche, sinnvolle Namen zu herzuleiten stelle ich mir unübersichtlicher vor. Wie würde bei deinem Beispiel guter Vorschlag aussehen?

Korrekt und im Sinne von Clean-Code sauber wäre die Einführung einer Parameter-Klasse und eine einzige Methode:

Delphi-Quellcode:

AddControl (Property, LayoutParams);

Dann ist es aber Essig mit 'schnell ein Layout zusammentippen', denn

Delphi-Quellcode:

//statt
AddControl(MyProperty,'Name',50);
//
// schreibt man nun
//
LayoutParams := TLayoutParams.Create;
LayoutParams.Label :='Name';
LayoutParams.Width := 50;
AddControl (MyProperty,LayoutParams);

Klar, sauber, einfach. Und umständlich(er). Imho auch leichter zu testen (das wäre aber zu beweisen).

Man muss sich einfach mal dran gewöhnen (imho), das gute Softwareentwicklung mit Dahingeschreibsel (aka Bequemlichkeit) nicht mehr viel zu tun haben kann. Es kommt nur noch auf Testbarkeit, sauberes Design, klare Strukturen usw. an. Bequemlichkeit hat da keinen Platz mehr.

Gestern hat man eine Klasse in 1 Stunde erstellt. Heute dauert das 2-3 Stunden, weil die Unittests noch geschrieben werden müssen und man CC einhalten muss/sollte.

Wir räumen gerade ein Schrottprojekt auf und bei jedem Bugfix (5 Minuten) folgt Refactoring (2-4 Std), Unittests (2 Std) und Schreibkram (0.5 - 1 Std). Hobbyprogrammierer müssen das natürlich nicht so machen.

Zitat:

Zitat von mkinzler (Beitrag 1237005)

Zitat:

Zitat von Furtbichler (Beitrag 1236970)

Das werden hier nun mal immer Grundsatzdiskussionen.

Bei denen sich komischerweise immer die selben Mitglieder beteiligen. :stupid:

Unter denen sich eben auch Softwarearchitekten befinden. Oder einfach nur Programmierer, die ein Interesse an Fundamentalem haben, weil sie über den Tellerrand blicken. Beteilige dich doch einfach daran.

[mkinzler]

Zitat:

Zitat von mkinzler:
Zitat von Furtbichler:
Das werden hier nun mal immer Grundsatzdiskussionen.
Bei denen sich komischerweise immer die selben Mitglieder beteiligen.
Unter denen sich eben auch Softwarearchitekten befinden. Oder einfach nur Programmierer, die ein Interesse an Fundamentalem haben, weil sie über den Tellerrand blicken. Beteilige dich doch einfach daran.

Dafür kann man geren einen eigene Thread eröffnen, aber nicht ständig andere Threads kapern

[jaenicke]

Zitat:

Zitat von Furtbichler (Beitrag 1237008)

Es ist wohl ein riesen Unterschied, ob ich eine Methode vollständig korrekt benenne, oder Nomenklaturdadaismus à la 'Jänickes Satirekabinett' (Damit ist nur die Überzeichnung von Sebastians Antwort gemeint) veranstalte.

Das war natürlich auch auf das Beispiel bezogen übertrieben gemeint. Bei umfangreicheren Funktionen läuft es aber trotzdem auf ähnliche Monsterbezeichner heraus.

Zitat:

Zitat von Furtbichler (Beitrag 1237008)

Dann ist es aber Essig mit 'schnell ein Layout zusammentippen', denn

Delphi-Quellcode:

//statt
AddControl(MyProperty,'Name',50);
//
// schreibt man nun
//
LayoutParams := TLayoutParams.Create;
LayoutParams.Label :='Name';
LayoutParams.Width := 50;
AddControl (MyProperty,LayoutParams);

Klar, sauber, einfach. Und umständlich(er).

Das nutzen wir auch so an einigen Stellen, auch mit Interfaces als Parameterinformation, wenn es sonst zu viele Parameter würden.

Man sieht dann besser welche Parameter eigentlich was machen. Bei guten Variablennamen sollte das ohnehin nicht so ein Problem sein, aber wenn das ein paar mehr Parameter sind, reicht das nicht mehr immer.

[JasonDX]

Zitat:

Zitat von Furtbichler (Beitrag 1237008)

Dann ist es aber Essig mit 'schnell ein Layout zusammentippen', denn

Delphi-Quellcode:

//statt
AddControl(MyProperty,'Name',50);
//
// schreibt man nun
//
LayoutParams := TLayoutParams.Create;
LayoutParams.Label :='Name';
LayoutParams.Width := 50;
AddControl (MyProperty,LayoutParams);

Klar, sauber, einfach. Und umständlich(er).

Guter Vorschlag. Mit Builder-Pattern wird das ganze sogar weniger umständlich (keine zusätzliche Variable) und leserlicher:

Code:

addControl(myProperty, LayoutParams.newBuilder()
  .setLabel('Name')
  .setWidth(50)
  .build());

Zitat:

Zitat von Furtbichler (Beitrag 1237008)

Man muss sich einfach mal dran gewöhnen (imho), das gute Softwareentwicklung mit Dahingeschreibsel (aka Bequemlichkeit) nicht mehr viel zu tun haben kann. Es kommt nur noch auf Testbarkeit, sauberes Design, klare Strukturen usw. an. Bequemlichkeit hat da keinen Platz mehr.

Es kommt draufan. Oft bringen sauberes Design und klare Strukturen auch bequemeres Coden und Testbarkeit - entsprechend fördert der Wunsch nach bequemen Coden auch sauberes Design und klarere Strukturen, und damit Testbarkeit. Also schließen sie sich nicht aus, Bequemlichkeit sollte nur nicht das Argument sein.

[Furtbichler]

Zitat:

Zitat von JasonDX (Beitrag 1237043)

Es kommt drauf an. Oft bringen ...

Stimmt, meine Aussage war zu allgemein. Sie trifft in erster Linie auf die Overload-Thematik zu.

[JamesTKirk]

Zitat:

Zitat von Furtbichler (Beitrag 1237008)

Zitat:

Zitat von JamesTKirk (Beitrag 1237004)

Und die WinAPI braucht sich da auch nicht verstecken, man denke da nur an

Delphi-Quellcode:

ConvertSecurityDescriptorToStringSecurityDescriptor

und Co :mrgreen:

Es ist wohl ein riesen Unterschied, ob ich eine Methode vollständig korrekt benenne, oder Nomenklaturdadaismus à la 'Jänickes Satirekabinett' (Damit ist nur die Überzeichnung von Sebastians Antwort gemeint) veranstalte. Was wäre Dir denn lieber?
'CnvScDsc2StrScDsc'?

Wo hab ich gesagt, dass mir eine kürzere Form lieber wäre? Mir ging es nur darum zu zeigen, dass auch eine C-basierte API (im Gegensatz zu einer objektorientierten API) wie die WinAPI durchaus auch lange, sprechende Namen haben kann und durchaus auch hat.

Gruß,
Sven

[Furtbichler]

Zitat:

Zitat von JamesTKirk (Beitrag 1237144)

Wo hab ich gesagt, dass mir eine kürzere Form lieber wäre? Mir ging es nur darum zu zeigen, dass auch eine C-basierte API (im Gegensatz zu einer objektorientierten API) wie die WinAPI durchaus auch lange, sprechende Namen haben kann und durchaus auch hat.

Dann war es ein Mißverständnis. :oops: