PureBoard

'es' ist definitv kein pronomen für 'Ergebnis'.
https://deutschegrammatik20.de/2014/05/ ... ng-von-es/
Ich denke in Frage kommt 'Es als Platzhalter für den Nominativ' oder 'Obligatorisches Es beim Passiv'.
'es' gehört also entweder zum Verb, oder zu String$ (dem Parameter, nicht dem Rückgabewert).

da das Ergebnis der als Parameter übergebene 'String$' ist, der geändert wird

Eigentlich hast du Recht, das geht auch.

Kurzer hat geschrieben:Mich würde einfach nur noch interessieren auf was sich das Wort "es" deiner Meinung nach bezieht. Mir reicht es nicht, wenn man sagt, dass es nichts mit dem Ergebnis zu tun hat. Auf irgendwas muss es sich doch auch in deinem Satzverständnis beziehen, nur auf was?

Ich schrieb es bereits: Das ist wie in dem Satz "Es ist Peter, der das Spiel gewonnen hat".

Kurzer hat geschrieben:PS: Immerhin ist man im englischen Forum auch der Meinung, das diese Passage in der Hilfe nicht wirklich optimal formuliert ist.

Im englischen Forum geht es nicht um die deutsche Hilfe, sondern um die Formulierung in der englischen Hilfe.

Letzter Versuch:

Es heißt in der Hilfe ganz klar: "Wenn diese Option verwendet wird, muss das Ergebnis von ReplaceString() ignoriert werden". Also warum soll sich der Autor der Hilfe noch weiter auf das Ergebnis beziehen, wenn es sowieso ignoriert werden muss?

Hilfe hat geschrieben:Wenn diese Option verwendet wird, muss das Ergebnis von ReplaceString() ignoriert werden (und auch nirgends zugewiesen - da es der als Parameter übergebene 'String$' ist, der geändert wird).

Nach deiner Interpretation würde das etwa heißen:
"Wenn diese Option verwendet wird, muss das Ergebnis von ReplaceString() ignoriert werden (und auch nirgends zugewiesen - weil Rückgabe von ReplaceString() bei Verwendung von #PB_String_InPlace genau dem Eingangsstring entspricht)."

Das ist doch nun offensichtlicher Unsinn:
Selbst wenn die Rückgabe von ReplaceString() bei Verwendung von #PB_String_InPlace genau dem Eingangsstring entspräche, wäre das keine Begründung dafür, dass das Ergebnis von ReplaceString() ignoriert werden muss ...

#NULL hat geschrieben:'es' ist definitv kein pronomen für 'Ergebnis'.
https://deutschegrammatik20.de/2014/05/ ... ng-von-es/
Ich denke in Frage kommt 'Es als Platzhalter für den Nominativ' oder 'Obligatorisches Es beim Passiv'.
'es' gehört also entweder zum Verb, oder zu String$ (dem Parameter, nicht dem Rückgabewert).

Man, da kriegt man ja Knoten ins Hirn.

Okay, ich verstehe jetzt was du meinst. Ich weiß nicht, ob es bei den Menschen unterschiedliche Assoziationspräferenzen gibt, aber die Version, dass sich "es" auf den "Parameter" bezieht, war für mich völlig abwegig - quasi nicht existent, mental nicht sichtbar.

Von daher würde ich den Satz in der Hilfe wirklich anders schreiben:

Wenn diese Option verwendet wird, muss das Ergebnis von ReplaceString() ignoriert werden und darf auch nicht zugewiesen werden, da die Rückgabe der Funktion undefiniert ist. Die String-Ersetzung wird direkt in dem als Parameter übergebenen 'String$' durchgeführt.

Nino hat geschrieben:Im englischen Forum geht es nicht um die deutsche Hilfe, sondern um die Formulierung in der englischen Hilfe.

Die als Basis für die deutsche Hilfe steht und daher die gleichen Informationen (in anderer Sprache) vermitteln sollte. Ich denke, wenn das Doku-Team die englische Hilfe anpasst, hat dies auch Auswirkungen auf die daraus resultierende deutsche Hilfe. Für mich hat die Formulierung sowohl in der deutschen als auch in der englischen Hilfe bzgl. des Rückgabewertes einen zu hohen Interpretationsspielraum.

Es mag ja sein, dass ich da eine, wie auch immer begründete, Ausnahme bin, aber wenn ich es nicht zur Sprache bringe und für mich zu klären versuche, kann ich auch nicht feststellen, ob das Problem ein globales Problem ist oder nicht. Selbst, wenn ich das einzige Liguisten-Alien hier sein sollte, dann ist es zumindest für mich hilfreich das zu klären. Ich mache mich ja nicht zum Spaß zum Affen. Im wirklichen Leben hat es solche Interpretationsprobleme übrigens noch nicht gegeben, sonst hätte ich die Ursache sicherlich zuerst bei mir gesucht.

Kurzer hat geschrieben:

Nino hat geschrieben:Im englischen Forum geht es nicht um die deutsche Hilfe, sondern um die Formulierung in der englischen Hilfe.

Die als Basis für die deutsche Hilfe steht und daher die gleichen Informationen (in anderer Sprache) vermitteln sollte. Ich denke, wenn das Doku-Team die englische Hilfe anpasst, hat dies auch Auswirkungen auf die daraus resultierende deutsche Hilfe.

Wenn in einer Sprache etwas falsch oder missverständlich geschrieben ist, sagt dass nocht nichts darüber aus, wie der Text in einer anderen Sprache geschrieben ist. Die einzige Aussage im englischen Forum über die deutsche Hilfe ist, dass sie "clear and correct" ist (Josh).

Siehe mein Edit (letzter Absatz im vorherigen Post - wir haben uns überschnitten).

Im übrigen sind ja offenbar beide Interpretationsmöglichkeiten richtig, wie #NULL festgestellt hat. Insofern solltest du dein 'an den Haaren herbeigezogen' evtl. überdenken.

Kurzer hat geschrieben:Im übrigen sind ja offenbar beide Interpretationsmöglichkeiten richtig, wie #NULL festgestellt hat.

Nein, sind sie sinnvoller Weise (ohne an den Haaren zu ziehen) eben nicht!
Spätestens dieser Beitrag von mir sollte das geklärt haben.

Kurzer hat geschrieben:Insofern solltest du dein 'an den Haaren herbeigezogen' evtl. überdenken.

Nö, dafür gibt es keinen Grund.

Nino hat geschrieben:

Kurzer hat geschrieben:Im übrigen sind ja offenbar beide Interpretationsmöglichkeiten richtig, wie #NULL festgestellt hat.

Nein, sind sie sinnvoller Weise (ohne an den Haaren zu ziehen) eben nicht!
Spätestens dieser Beitrag von mir sollte das geklärt haben.

In deinem Post ist ein Edit drin, offenbar hast du später was zugefügt oder ich habe es übersehen, also reiche ich hiermit nach:

Nino hat geschrieben:Es heißt in der Hilfe ganz klar: "Wenn diese Option verwendet wird, muss das Ergebnis von ReplaceString() ignoriert werden". Also warum soll sich der Autor der Hilfe noch weiter auf das Ergebnis beziehen, wenn es sowieso ignoriert werden muss?

Das kann nur der Autor beantworten. Evtl. wollte der Autor dem Leser erklären, warum der Rückgabewert zu ignorieren ist. Eigentlich ist es klar warum, weil der Eingangsparameter das Ergebnis enthalten wird, aber da in der Hilfe trotzdem ein erklärender Nebensatz steht, ging ich davon aus, dass es als optionale Erklärung zu dem "Warum ist er zu ignorieren" dient. Quasi, damit man sich nicht wundert, dass der erste Parameter als Ergebnis zurückgegeben wird. So habe ich es zumindest verstanden.

Warum die Funktion den ersten Parameter zurückgeben sollte? Was weiß ich? Ich kenne den internen Aufbau von ReplaceString() nicht. Es hätte einfach mit Geschwindigkeitsvorteilen zu tun haben können, dass kein code existiert, um eine definierte Rückgabe zu liefern (z.B. #True und #False).

Nino hat geschrieben:Selbst wenn die Rückgabe von ReplaceString() bei Verwendung von #PB_String_InPlace genau dem Eingangsstring entspräche, wäre das keine Begründung dafür, dass das Ergebnis von ReplaceString() ignoriert werden muss ...

Genauso wie es technisch keine Begründung dafür gibt das Ergebnis zu ignorieren, wenn die Funktion das zurückgibt was sie derzeit zurückgibt (einen früher verwendeten Stringbuffer).

Im übrigen habe ich deine Interpretation der Hilfe ja mittlerweile ebenfalls anerkannt, da #NULL so freundlich war und die Bezüge endlich mal beim Namen genannt hat. Und ich habe auch erklärt, dass ich das hier nicht zum Spaß mache, sondern (so unglaubwürdig es für dich evtl. klingen mag) für mich der Bezug zum Parameter String$ auch nach seitenlangem Lamentieren nicht sichtbar war. Siehe dazu den letzten Absatz in diesem Beitrag: viewtopic.php?p=356323#p356323

Eigentlich ist doch jetzt alles gesagt, oder? Weil... ich wäre jetzt so langsam reif für ein Bier.

Ich geb's jetzt endgültig auf ...

Es tut mir leid, dass meine Synapsenstruktur mit deiner nicht in Einklang zu bringen war.
Aber ich kann dich beruhigen, ich kann den Satz nun auch so sehen wie du. Das konnte ich vorher aus mir nicht erklärbaren Gründen nicht.