Ankündigung

Einklappen
Keine Ankündigung bisher.

php contracts

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • php contracts

    Moin,

    ich bin gerade auf die Idee gekommen, eine Liste mit coolen Interfaces zu erstellen. Das einzig wirklich brauchbare ist bislang wahrscheinlich die Wunschliste.

    Hat jemand noch etwas, was man da hinzufügen kann?

  • #2
    Sind die aus der "Unstable"-Abteilung denn "cool"? PSR-Cache... Bin mir noch nicht sicher, was ich davon halten soll.

    Kommentar


    • #3
      Das was du da vor hast ist mit den von dir gelisteten 3rd Parties unmöglich, da du auf deren Veränderung mit Änderungen deiner Standardisierung oder durch Adapter reagieren musst.

      PHP Standard Contracts sind soweit "dumm", da sie bis auf wenige Mechaniken sich von heute auf morgen verändern können ( und werden ). PSR stößt auf das selbe Problem und hat schon seinen ersten "Standard" gegen die Wand gefahren ( als deprecated markiert ).
      [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

      Kommentar


      • #4
        Zitat von tr0y Beitrag anzeigen
        Das was du da vor hast ist mit den von dir gelisteten 3rd Parties unmöglich, da du auf deren Veränderung mit Änderungen deiner Standardisierung oder durch Adapter reagieren musst.
        Ich kann dir an dieser Stelle nicht folgen.

        Zitat von tr0y Beitrag anzeigen
        PHP Standard Contracts sind soweit "dumm", da sie bis auf wenige Mechaniken sich von heute auf morgen verändern können ( und werden ).
        Ein Psr/Log 1.0 bleibt auf ewig gleich.
        Wenn das PSR-Konsortium mal eine 1.1 veröffentlichen sollte, dann ist das ein abweichender Standard. Können Sie aber eigentlich nicht mehr unter psr/log. Das würde zu unüberwindbaren Inkompatibilitäten bei Projekten führen, die bereits 1.0 im Einsatz haben.

        Zitat von tr0y Beitrag anzeigen
        PSR stößt auf das selbe Problem und hat schon seinen ersten "Standard" gegen die Wand gefahren ( als deprecated markiert ).
        Mehr Information!

        Kommentar


        • #5
          https://github.com/php-fig/fig-stand...epted/PSR-0.md

          Deprecated - As of 2014-10-21 PSR-0 has been marked as deprecated. PSR-4 is now recommended as an alternative.
          Es gibt kein PSR Konsortium. Die PHP Framework Interop Group verwaltet die PSR-Standards. Aus meiner Sicht mit guten Ansätzen, allerdings lässt die Namensgebung der Standards und dessen Lebensspanne ( die jüngst durch das absetzen des PSR-0 Standards demonstriert wurde ) zu wünschen übrig.

          psr/log ist kein Standard per se, sondern ein Versuch ein Standard Komponenten Interface fürs Logging zu etablieren. PSR-3 ist der Logging Standard der PHP-FIG.
          [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

          Kommentar


          • #6
            psr/log ist die Referenzimplementierung der Abstraktion. Mit dem "Standard" alleine kann man nicht direkt etwas anfangen. Er dokumentiert aber die Schnittstelle und vereinbart ein allgemeines Verhalten das doch recht gewissenhaft ausgearbeitet wurde. Wesentlich sinnvoller, als sich an irgendwelche interface-losen Direktimplementationen zu binden.

            Und dass psr0 ein Rohrkrepierer war, war schon bei der Veröffentlichung klar.

            Kommentar


            • #7
              Zitat von rkr Beitrag anzeigen
              psr/log ist die Referenzimplementierung der Abstraktion. Mit dem "Standard" alleine kann man nicht direkt etwas anfangen. Er dokumentiert aber die Schnittstelle und vereinbart ein allgemeines Verhalten das doch recht gewissenhaft ausgearbeitet wurde. Wesentlich sinnvoller, als sich an irgendwelche interface-losen Direktimplementationen zu binden.

              Und dass psr0 ein Rohrkrepierer war, war schon bei der Veröffentlichung klar.
              Der deprecated Rohrkrepierer zersägt aber 60% aller PEARs und über die hälfte der Packagist Komponenten wenn PSR-0 ( prophetisch: im nächsten Jahr ) aus Composer rausfliegt.
              [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

              Kommentar


              • #8
                Welche Anzeichen siehst du da? Ich denke nicht, dass Jordi da was rauswirft, nur weil es deprecated ist. Deprecated heisst ja nur, dass man diesen Standard für neue Entwicklungen nicht mehr verwenden sollte. Und PEAR ist doch schon seit Jahren quasi deprecated!

                Kommentar


                • #9
                  Semi-OT:

                  Diesen Artikel zur phpfig fand ich neulich recht lesenswert: http://blog.ircmaxell.com/2014/10/an...o-php-fig.html Da geht es darum, dass die besser simple Basis-Interfaces anbieten sollten, statt zu versuchen, jeden denkbaren Anwendungsfall zu lösen. Er sagt darin glaube ich auch, dass es beim Logging halt zufällig mal leicht war, weil das Thema übersichtlich und gut durchdrungen ist. Das Logger-Interface folgt ja in wesentlichen Teilen einem RFC:

                  The LoggerInterface exposes eight methods to write logs to the eight RFC 5424 levels (debug, info, notice, warning, error, critical, alert, emergency).
                  - https://github.com/php-fig/fig-stand...r-interface.md

                  Ansonsten bin ich nach wie vor sehr unbeeindruckt davon, was die tun. Um Lösungen für die gesamte Community geht es denen aber auch gar nicht.

                  The idea behind the group is for project representatives to talk about the commonalities between our projects and find ways we can work together. Our main audience is each other, but we’re very aware that the rest of the PHP community is watching. If other folks want to adopt what we’re doing they are welcome to do so, but that is not the aim.
                  - http://www.php-fig.org/

                  Mir kommt dazu immer nur der Begriff circle jerking in den Sinn.

                  Und was die Zusammenarbeit von Frameworks angeht, habe ich nicht das Gefühl, dass die einzelnen Framework-Communities besonders interessiert daran sind, ihren Entwicklungsprozess kompliziert mit der FIG zu koordinieren. (Was eigentlich auch ein absurder Gedanke ist.)

                  PS: Und PSR-2, der freaking Coding Style Guide, enthält noch immer peinliche formale Fehler. (Und verletzt sich in seinen Beispielen selbst.) Ich finde, so was wirft schon kein ganz gutes Licht auf die Sache.

                  PPS: Mein „Gegenbeispiel“ zur phpfig ist immer Composer. Die lösen einfach das Problem. Du willst eine Class-Map, um deine Klassen zu laden? Kein Problem, wir generieren dir die sogar.

                  PPPS: Es ist jetzt auch nicht so, dass Autoloading erst seit der phpfig funktioniert. Diese Sache mit „PEAR-Style = Namespaces = Verzeichnisse“ war auch davor schon verbreitet. Die haben da in dem Sinne kein Problem gelöst.

                  Kommentar


                  • #10
                    @mermshaus:
                    Also in der PHP-Welt verlangt aktuell niemand wirklich diesen einen Standard der all unsere Probleme löst. Das hat auch in der Java-Welt nicht immer gut funktioniert, obwohl die Schnittstellen dort schon sehr akribisch ausgearbeitet wurden.

                    Wenn wir schon mal irgendeine Kommunikationsbasis hätten, auf der man Projektübergreifende Komponenten nach „Vertrag“ designen kann, dann hätten wir damit schon eine Menge gewonnen.

                    Ich habe den Beitrag von Herrn Ferrara und stimme damit nicht vollständig überein. Dass die FIG jetzt mal den Hintern hochbekommt und statt der tausendsten inkompatiblen propritären Caching-Komponenten endlich mal eine dokumentierte Schnittstelle zu schaffen, finde ich gut. Wenn die Schnittstelle meinen Bedürfnissen entspricht, dann kann ich sie in meinem Projekt nutzen. Dadurch habe ich eine mögliche Schnittstelle zu verschiedenen Caching-Komponenten geschaffen. Wenn es nicht passt, dann bau ich mir halt etwas Eigenes und schreibe Adapter dafür.

                    Eine 50%-Lösung zu schaffen geht am Punkt vorbei. Sie löst dann ja kein Problem, sondern schafft eher neue. Caching-Artifacts brauchen nun mal ein ttl – pro Artifact. So funktionieren Caches in der Echtwelt. Transaktionen hingegen sind in der Caching-Welt dann eher unüblich. Ohnehin eine komische Idee, Transaktionen! Kein halbwegs ausgeschlafener Architekt nimmt an, dass er bei einem allgemeinen Caching-Interface Transaktionen verwenden könnte. Dann sollte man in einem Cache alles speichern dürfen. Auch NULL. Ein Interface sollte eine „has“ oder „exists“ Methode haben. Wenn eine Implementation das nicht unterstützt, sollte man das Problem abstrahieren und ggf. einen zweiten Caching-Eintrag schreiben, der dann Metainformationen zum eigentlichen Eintrag bereithält. Das ist dann aber Implementationsstategie! Hat er ja auch passend formuliert.

                    Es gibt ein paar Komponenten (https://github.com/ziadoz/awesome-php), die in der PHP-Community akzeptiert und oft eingesetzt werden. Schaut man sich diese Komponenten an, dann sieht man häufig ein klares Muster auf Basis dessen man schon einen Designvertrag entwickeln könnte. Wenn es dann fünf große Verträge für „Caching“ gibt, dann ist das doch super! Vorausgesetzt, dass ich für die wichtigsten Komponenten zumindest entsprechende Adapter bekomme. Das ist nicht so schwer, als dass man das nur bei Typen von Schnittstellen wie PSR-3 machen könnte.

                    Kommentar


                    • #11
                      Laravel wird das in Version 5 auch durchziehen mit den Contracts: https://github.com/laravel/framework...nate/Contracts

                      Kommentar


                      • #12
                        Zitat von rkr Beitrag anzeigen
                        Dann sollte man in einem Cache alles speichern dürfen. Auch NULL. Ein Interface sollte eine „has“ oder „exists“ Methode haben.
                        Ich habe den Post auch gelesen und warum man null nicht speichern dürfen sollte wird mir in diesem Leben nicht mehr klar werden. Das scheint mit eigentlich nicht mal diskussionswürdig.

                        Kommentar

                        Lädt...
                        X