Array-Bibliothek mit fehlenden Funktionen gesucht

[rkr]

Moin,

bevor ich jetzt selbst was anfange:
Ich suche eine Bibliothek, die verschiedene Array-Funktionen zur Verfügung stellt. Würde ich das jetzt selbst bauen, würden da unter anderem folgende Funktionen reinkommen:

arr/intersect($array, $values);
arr/intersectKeys($array, $keys);
arr/diff($array, $values);
arr/diffKeys($array, $keys);
arr/filter($array, $callable, $includeKeys = false);
arr/filterKeys($array, $callable, $includeValues = false);
arr/map($array, $callable, $includeKeys = false);
arr/mapKeys($array, $callable, $includeValues = false);
arr/mapRecursive($array, $callable, $maxDepth = null, $includeKeys = false);
arr/mapKeysRecursive($array, $callable, $maxDepth = null, $includeKeys = false);
arr/has($array, $key);
arr/get($array, $key, $default = null);
arr/set($array, $key, $value);
arr/group($array, $callable, $maxDepth=null); 

Meine Frage jetzt: Kennt jemand eine Bibliothek, wo ähnliche Funktionen bereits implementiert sind? Müssen natürlich nicht alle sein.

[Ma27]

Ich scheitere regelmäßig an der Reihenfolge der Parameter von strpos

Oh gott - das passiert mir, trotz guter IDE, wirklich immer, wenn ich strpos nutze.
Ist aber auch eine der wenigen (wenn nicht sogar die einzige) mit der Reihenfolge Haystack - Needle.

LG

//OT:
wo wir dabei sind:

int strpos ( string $haystack , mixed $needle [, int $offset = 0 ] )

mixed strpos ( string $haystack , mixed $needle [, int $offset = 0 ] )

gibt es ne stelle wo man inkonsistenzen in den übersetzungen der docu reporten kann.
ist das mit int/mixed überhaupt ein report wert?

[lottikarotti]

PS: ich hab mir nach 14 Jahren PHP immer noch nicht merken können ob nun php_info() oder phpinfo()

Ich scheitere regelmäßig an der Reihenfolge der Parameter von strpos

[erc]

//OT:
Ich hänge immernoch an dem naiven glauben, dass bei opensourceprojecten sinnvolle und praktische änderungen übernommen werden.
auch wenn dass sicher nicht gemeint war.

Ja, aber wenn du die Signaturen von den Funktionen änderst wird das nie niemals übernommen werden. Dieses ganze Funktions Wirrwarr ob mit Unterstich oder ohne, ob needle/haystack oder haystack/needle, ob nun array_, str_ oder nicht, das ist den Entwicklern auch klar. Es wird aber nicht geändert weil es die kompatibilität brechen würde.

PS: ich hab mir nach 14 Jahren PHP immer noch nicht merken können ob nun php_info() oder phpinfo()

Ja genau, es macht komplett sinn seine eigene Programmiersprache zu pflegen. Das kann sich ein Facebook leisten, aber die machen das bestimmt nicht aus dem Grund "Uns gefallen die Array Funktionen nicht.".

//OT:
Ich hänge immernoch an dem naiven glauben, dass bei opensourceprojecten sinnvolle und praktische änderungen übernommen werden.
auch wenn dass sicher nicht gemeint war.

[Arne Drews]

Das war an erc gerichtet, aber egal...

[rkr]

Naja, wenn Du das nochmal in Ruhe liest und drüber nachdenkst, wirst Du sicher drauf kommen, warum ich das geschrieben habe...

Habe ich. Das Licht ging nicht an.

[Arne Drews]

Naja, wenn Du das nochmal in Ruhe liest und drüber nachdenkst, wirst Du sicher drauf kommen, warum ich das geschrieben habe...

[erc]

Aber wenn Du - so wie Du mehrfach betont hast - die Array-Funktionen von PHP so schlecht designed findest, dann würde ich mir den Source-Code schnappen und die entsprechenden Funktionen anpassen bzw. neue implementieren.
Denn hast zwar Deine eigene Kompilation, aber dann macht es wenigstens richtig Sinn.

Ja genau, es macht komplett sinn seine eigene Programmiersprache zu pflegen. Das kann sich ein Facebook leisten, aber die machen das bestimmt nicht aus dem Grund "Uns gefallen die Array Funktionen nicht.".

[Arne Drews]

Wenn ich mir Deine Bibliothek ansehe, erkenne ich den großen Wurf leider nicht, sorry.
Nicht, daß ich Deine Anpassungen nicht tlw. auch für praktisch halte...

Klar, wenn ich etwas erreichen möchte, was mit den PHP-Standard-Bibliotheken nicht per Einzeiler lösbar ist, ich dieses aber häufig benötige, schreibe ich mir auch eine Funktion bzw. erweitere eine meiner bereits vorhandenen Helper-Klassen, je nachdem, wie es mir dann sinnvoll erscheint.

Aber wenn Du - so wie Du mehrfach betont hast - die Array-Funktionen von PHP so schlecht designed findest, dann würde ich mir den Source-Code schnappen und die entsprechenden Funktionen anpassen bzw. neue implementieren.
Denn hast zwar Deine eigene Kompilation, aber dann macht es wenigstens richtig Sinn.

Falls Du Interesse hast, den Source gibts hier: PHP Downloads

[rkr]

Wenn ich mit ArrayObjekt arbeite, muss ich um jedes Array erst mal ein Objekt wrappen. In dem Moment wo ich das tue, kann ich verschiedene Standardfunktionen (wie array_merge) nicht mehr nutzen.

Je nach Projekt kann der Einsatz von Arrays sehr selten oder massiv häufig sein. Viele Komponenten nutzen arrays als Möglichkeit, komplexe Parameter zu schlucken. Es jst überhaupt nicht üblich, ein ArrayObjekt als Parameter zu erwarten. Arrays werden defacto überall für das eingesetzt, was sie sind. Arrays eignen sich auch gut, um via ajax Informationen auszutauschen. Durch angular ist mein Gebrauch von Arrays auch wieder gestiegen.

Syntaktisch sind arrays auch wesentlich angenehmer und vielseitiger einsetzbar als die objektvarianten ArrayAccess und ArrayObjekt.

Wenn du Funktionen einsetzt, kannst du den Funktionsumfang beliebig erweitern, ohne dass du ein Gottobjekt erweitern musst.

Der Basisumfang von ArrayObjekt ist lächerlich. Deine Erweiterungen decken längst noch nicht alle einfachen Fälle ab. "Lyst" wäre viel zu groß wenn es alles könnte, was man theoretisch benötigt. Ich spreche aber nach wie vor von generaliaierten Belangen. Die php array-Funktionen sind zT schlecht designt und decken an sich schon eher spezielle Bereiche ab.

Dann kann ich nicht mehr "array" als Typehint verwenden. In manchen Situationen kann das zu einer Verbesserung führen, da arrays bekanntermaßen bei Übergabe kopiert werden. Jedoch setzen viele Standardfunktionen arrays als Parameter voraus und nehmen ArrayObjekt als Ersatz nicht an.

Vielleicht wäre die optimale Lösung etwas dazwischen. Quasi sowas wie jQuery wo Lyst eher sowas wie Prototype und meins eher sowas wie plain js ist. So könnte man auch das autoloading bedienen.

[tr0y]

Ich weiß nicht ob ich (d)eine Bibliothek heute noch als solche einstufen würde. Schau ich mir die heutigen Bibliotheken so an, die viel genutzt und weit verbreitet weitergereicht werden hab ich dort Klassen vor mir, die partiell auto-geladen werden. Klar ist OOP oder POP eine Design-Entscheidung, ich würde heute aber nicht mehr hingehen und mit functions rumfuchteln wollen geschweige denn Bibliotheken auf functions runterbrechen.

Wenn dir ArrayObjects nicht zusagt, wären Adapter eine Option ( jeweils einen für die jeweiligen Aufgaben: Map, Slice, Group, Combine, ... ).

[rkr]

Wolltest du jetzt nur mitteilen, dass du den Thread gelesen hast (falls ja, dann danke), oder hast du auch Belege dafür, dass ich damit vor allen Dingen eigene Probleme lösen möchte, bzw das die Bibliothek keine generellen Probleme löst?

[Arne Drews]

Ne, das ist Zwillingen vorbehalten...