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

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...

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.

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.

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...

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.