_regex_split - StringSplit aber mit regulärem Ausdruck als Trenner

  • Im Grunde ist das nix großes - daher keine extra UDF hierfür.
    Worum geht es?: Mit StringRegExp können wir uns die Teile eines Strings zurückgeben, welche einem bestimmten Muster entsprechen. In anderen Sprachen gibt es jedoch noch einen weiteren Ansatz:
    Dort kann man Strings anhand von Trennstrings trennen, deren Muster sich aus einem regulären Ausdruck ergibt.
    Das kann je nach Anwendungsfall einfacher sein als sich ein Muster zu überlegen welches alles andere definiert.

    Im Prinzip funktioniert es wie StringSplit - nur dass man anstatt einem Trennstring eben ein Trenn-Pattern angibt.

    Hierfür dient nun folgende Funktion (kann sein dass soetwas schonmal ein anderer gemacht hat):

    Edit:

    Nach etwas Überlegen ist mir ein Ansatz eingefallen, welcher wohl in allen Belangen (Codegröße, Ausführungsgeschwindigkeit, Verständlichkeit) der obige Version überlegen ist.
    Ich würde daher dazu raten eher diese Funktion zu verwenden:

    Einmal editiert, zuletzt von AspirinJunkie (23. März 2023 um 10:23) aus folgendem Grund: Bessere Funktion ergänzt

  • Hi AspirinJunkie,

    [...] kann sein dass so etwas schonmal ein anderer gemacht hat [...]

    ich meine etwas ähnliches (mit gleichem Ziel) im AutoIt Snippets Thread (des engl. Forums) gesehen zu haben, doch anstatt sich durch die mittlerweile dort 24 pages zu navigieren, kann man nun einfach deine Funktion nutzen 😀 . Danke dir.

    Viele Grüße
    Sven

  • Also ich finde gerade so etwas eine sinnvolle "Erweiterung" der vorhandenen Funktionen.

    Es wäre natürlich noch schöner das in einer zu kombinieren. Sprich sowas wie:

    AutoIt
    _SringSplit($String, $Method, $Delimiter, $flag) 
    ;String = der zu trennende String
    ;Method = True für RegEx, False für default Stringsplit
    ;Delimiter = Delimiter für Stringsplit bzw. Pattern für RegEx
    ;flag = Flags fürs Stringsplit
  • Ja viel mehr als ein kleines Snippet ist es ja nicht.
    Fand es dennoch für evtl. nützlich für einige und hatte keinen anderen Ort um es zu veröffentlichen.

    Ist doch genau der richtige Ort dafür AspirinJunkie, denke ich 😀 .

    [...] Es wäre natürlich noch schöner das in einer zu kombinieren [...]

    Ich verstehe deine Überlegung Moombas, würde dennoch das Kombinieren ehrlich gesagt als unsauber empfinden.
    Es sind zwei verschiedene Aufgaben, die StringSplit() und _regex_split() haben, daher würde ich dies nicht zusammen fassen.

    Was jeder Einzelne von uns tut, sei jedem selbst überlassen 😇 . Kannst dir ja die Funktion soweit erweitern, falls du dies nicht sowieso schon gemacht hast.

    Danke nochmal fürs Teilen AspirinJunkie.

    Viele Grüße
    Sven

  • Es wäre natürlich noch schöner das in einer zu kombinieren

    So sehe ich das auch, allerdings nicht als (wie dein Vorschlag) script breaking change sondern die "Methode" ans Ende der Funktionsvariablen gestellt.

    StringSplit ( "string", "delimiters" [, flag = 0] , [method =0] )

    Dann wäre die Erweiterung wirklich eine Erweiterung und könnte so (problemlos?!) übernommen werden und würde keinen "normalen" Verwender von Stringsplit() wirklich stören.

  • Es war ja auch nur ein Q&D Beispiel und da habe ich mir persönlich keine Gedanken über Script breaking change gemacht. AAber dein Einwand Andy macht absolut Sinn.

    SOLVE-SMART für mich ist es die gleiche Aufgabe: "das Zerteilen eines Strings" Ob das nun per RegEx oder einfachem Delimiter passiert, ist doch egal. Die Aufgabe/das Ziel ist das Gleiche. Aber evtl. denken wir hier etwas unterschiedlich.

  • Naja script-breaking wäre es ja nicht, da es die Funktion _StringSplit() bisher nicht gibt.
    Ich persönlich würde die auch nicht zusammenmischen wollen, da die Trennung was nun gerade wirklich gemacht wird über den Funktionsnamen eher ersichtlich als über einen Parameter ganz hinten.
    Aber das ist schlicht Geschmackssache.

    Wenn sich jemand aus dem Code eine entsprechende _StringSplit() bauen möchte, kann er das ja machen - der Code ist ja keine Raketentechnik.

    Es geht ja auch ausschließlich um eigenen Code, da wir eh keinen Einfluss auf die AutoIt-Funktionen selbst haben.
    Von daher hat hier jeder alle Freiheiten.

  • Ob das nun per RegEx oder einfachem Delimiter passiert, ist doch egal. Die Aufgabe/das Ziel ist das Gleiche.

    Eben! Ich bin auch grundsätzlich dafür, zusammengehörende "Features" zusammenzufassen. Warum?! Weil es absolut keinen Sinn macht Produkte aka Funktionen, Programme und auch Programmiersprachen neu zu "erfinden" weil keines der verfügbaren "Produkte" dessen Leistungsfähigkeit hat. Es ist wesentlich besser, ein neues "Feature" der Allgemeinheit mit einer allgemein verfügbaren Funktion zugänglich zu machen als ein "alleinstehendes" Produkt mit genau EINER Funktion und darauf zu warten, dass irgendwer, der ein bestimmtes Problem hat, irgendwann (zeitnah :rofl: ) zufällig darüber stolpert....

    (teilweise) OT:

    Weil ebendiese von den "Machern" geforderte Funktionalität bei den etablierten Werkzeugen fehlt bzw. unzureichend implementiert wurde (Designfehler?!) gibt es doch überhaupt neue "Erfindungen". Nur mal um darüber nachzudenken: Es gibt aktuell nur eine Handvoll Prozessorarchitekturen aber ca. 350 (produktive) bis 1500 (just for fun) Programmiersprachen....jaja..."das richtige Werkzeug für das Problem finden"...frei nach Tim Taylor:"If it doesn´t fit, use a Hammer!"

    Und jetzt mal ganz konkret: Wenn DU ein Prozessor wärest, der linear einzelne Befehle abarbeitet, wüßtest DU mit welcher Programmiersprache der Code erstellt wurde? Müsstest du das überhaupt wissen um die Aufgabe zu erledigen? Wieso sind 349 Programmiersprachen "so schlecht", dass eine komplett neue 350. "erfunden" werden muss?

    Und nein, bevor die Vermutung aufkommt, ich bin kein Verfechter der Zurschaustellung der "Featuritis" (Bsp. UI gängiger Officeprogramme...Victorinox Swisschamp XXL...)

    Was wirklich weiterbringt ist die Frage was der Anwender (von egal welchem Produkt) eigentlich machen will!

    Von daher hat hier jeder alle Freiheiten.