string.Split mit Count

[himitsu]

Halli Hallöchen,

die meisten SplitString-Funktionen behandeln das Count/Max so,
dass beim Treffen der letzte Eintrag ALLES bis zum Rest enthält,

HEIßT ALSO "trenne maximal in X Teile auf"
-> alles was rein geht, kommt auch wieder raus



das neue string.Split macht es aber anders und "unterschlägt" somit einen Teil der Eingabe

SO ALA "gib maximal die ersten X Teile zürück"



Was würdet ihr als "richtigeres" Verhalten erwarten? (ich leider Ersteres)
-> Bug oder nicht

[DaCoda]

Hi Himitsu,
ich wäre da auch deiner Meinung, also die erstere Variante (Die "alte" Variante).

Wenn du aber die alte Version als Source hast, kannst du dir die ja in eine eigene Unit packen und alles ist gut.
Ich habe für solche Sachen so eine tb.Utils.pas und umschiffe manchmal "moderne" Routinen...

[himitsu]

Klar ... selbstmachen geht immer, aber wäre es nicht toll, wenn die vorhandenen Dinge "richtig" funktionieren täten und man etwas einfach so benutzten könnte, wenn es schonmal da ist?

Im Grunde geht es hier also nur darum,
ob es als Feature-Request (es wäre toll, wenn ihr das so in den nächsten Jahrzähnten ändern/erweitern könntet, aber ihr ignoriert uns sowieso)
oder als Bug-Report (das müsst ihr unbedingt reparieren, auch wenn ihr es sowieso ablehnt und nicht machen werdet) eingereicht wird.

[Jasocul]

Ich hatte bisher noch keinen Bedarf für die Variante mit count/limit, kann mir aber für beide Ansätze sinnvolle Szenarien vorstellen. Meine erster Gedanke war, dass ich damit die Anzahl der Array-Elemente begrenze und nur Elemente habe, die das Split-Zeichen berücksichtigen. Dann müsste ich mir beim letzten Element auch keine Gedanken machen, ob es gesplittet ist. Andererseits kann es sinnvoll sein, die ersten X Elemente als "Header" zu betrachten und das letzte mit weiterführenden Infos.
Als intuitiver würde ich allerdings eher die erste Variante betrachten.

[jaenicke]

Ich persönlich nutze eine eigene Split-Funktion, bei der ich deutlich mehr Möglichkeiten habe. Bei mir gibt es z.B. eine Mindest- und Maximalanzahl, wobei diese bedeuten, dass ich das Ergebnis nur möchte, wenn es diese Kriterien erfüllt. Enthält es mehr oder weniger Teile, bekomme ich nichts zurück. Da gibt es noch weitere Optionen, u.a. analog zu der Delphi-Option ExcludeEmpty.

Ich persönlich würde nicht erwarten, dass ich im letzten Teil den Rest geliefert bekomme, würde aber vorher natürlich nachschauen, was passiert, wenn ich eine mir noch unbekannte Funktion nutze.

Die Splitoptionen sind aktuell aber ja sehr leer, da sollte es kein Problem sein (sollte ), eine Option dafür hinzuzufügen. Das Standardverhalten wird wohl kaum noch geändert werden, weil es vorher schon jemand so nutzen könnte...

[himitsu]

In meinem Fall ist es so, dass im "letzten" String auch das Trennzeichen manchmal mit enthalten sein könnte.

Eine Variante mit Optionen gibt es schon, wo man sowas vermutlich erweitern könnte.
Drum frag ich vorher nochmal etwas rum, um die Frage/Verbesserungsvorschlag noch etwas anpassen zu können, so an die Allgemeinheit.

Wenn man diese blöden Helper "einfacher" erweitern könnte, also bestehende Helper und dazu noch eigenes hinzugefügt ... vor allem Record-Helper kann man nichtmal vererben.

[Uwe Raabe]

Ich bin auch der Meinung, dass das aktuelle Verhalten nicht verändert werden darf und, wenn überhaupt, weitere Optionen das Mittel der Wahl sind.

Wie auch immer das dann auch realisiert würde, persönlich wäre ich schon irritiert, wenn der letzte Eintrag im Rückgabe-Array noch Trennzeichen enthalten würde ohne dass er gequoted wäre. Wie könnte man sonst feststellen, ob dieser Eintrag ein Reststring ist oder aus einem QuotedString entstanden ist.

Delphi-Quellcode:

var S1 := 'Hallo,Welt,Dies,ist,ein,RestString';
var S1 := 'Hallo,Welt,"Dies,ist,der,dritte,Eintrag"';

In dem Fall würde ich wohl eher einen separaten Out-Parameter vorziehen in dem dann der Reststring steht, der über das Limit (Count) hinausgeht.

Zitat von himitsu:

-> Bug oder nicht

Definitiv kein Bug sondern Personal Preference: Das erwartete Verhalten ist halt immer zu einem gewissen Teil subjektiv und fundiert oft nur auf einer aktuellen Problemstellung. In einen Jahr kann das schon wieder anders aussehen. Insofern kann es da kein richtig oder falsch geben.

Zitat von himitsu:

In meinem Fall ist es so, dass im "letzten" String auch das Trennzeichen manchmal mit enthalten sein könnte.

Das ist allerdings schon ein sehr spezieller Fall und sollte meiner Meinung nach nicht Grundlage für ein generelles Verhalten einer Funktion sein. Er ist insbesondere speziell, weil es ausschließlich für den letzten Eintrag eine Sonderrolle vorsieht (nämlich dass er Trennzeichen enthalten kann). Ich würde diesen letzten String einfach quoten um diese Sonderrolle auch deutlich zu machen. Das ließe sich leicht durch eine vorgeschaltete Bereinigungsfunktion erledigen. Das wäre allemal besser, als eine Erweiterung der Split-Funktion anzufordern, die lediglich diesen Sonderfall mit abdeckt.

[Rollo62]

Ohne das jetzt im Detail gecheckt zu haben, ich denke da verhalten sich auch andere Sprachen,
wie C#, Java, JS usw. sehr unterschiedlich zueinander.
Eine allgemein richtige Funktionsweise scheint es nicht zu geben, oder kennt jemand sowas?

Im Zweifel würde ich sagen, mach es so wie C#, Java, JS es machen.
Das scheint aber schwierig.

[Blup]

Es gibt auch andere String-Helper-Funktionen die nicht so arbeiten wie man vieleicht erwartet.
Beispiel "String.Join":

Delphi-Quellcode:

sNamen := sNamen.Join(',', [sTyp1, ...]);

Der Ausgangswert wird ignoriert.
Es wird ein neuer String aus den Elementen erzeugt.
Das Verhalten ähnelt eher einem Constructor.
Ich würde intuitiv erwarten, dass der Ausgangswert in sNamen mit einbezogen wird.

[Uwe Raabe]

Zitat von Blup:

Das Verhalten ähnelt eher einem Constructor.
Ich würde intuitiv erwarten, dass der Ausgangswert in sNamen mit einbezogen wird.

Da die Join Overloads alle class methods sind, sollte diese Verhalten aber eigentlich nicht verwundern.