Ankündigung

Einklappen
Keine Ankündigung bisher.

Verschlüsselung - Ergänzung Beispielklasse

Einklappen

Neue Werbung 2019

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

  • #16
    Zitat von rkr Beitrag anzeigen
    Ich meine, dass du die Phrase später einfach nicht mehr verändern kannst und damit das Objekt so bleibt wie es ist, egal wo es zwischenzeitlich war.
    https://eval.in/private/0573dc149db7dc

    PHP-Code:
    class Foo
    {
       private 
    $privateVal;
       public function 
    __construct$val )
       {
          
    $this->privateVal $val;
       }
    }

    $foo = new Foo17 );

    $refClass = new ReflectionClass$foo );
    $refProperty $refClass->getProperty('privateVal');
    $refProperty->setAccessibletrue );
    $refProperty->setValue$foo42 );
    print_r$foo ); 
    Also verändern geht immer…

    Gruß, Ulf
    PHP-Manual ¡ mysql_* ist veraltet ¡ Debugging: Finde DEINE Fehler selbst ¡ Passwort-Hashing ¡ Prepared Statements

    Kommentar


    • #17
      Und deutlich weniger kompliziert mit scoped Closure-Bindings..
      [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


      • #18
        Zitat von Ulfikado Beitrag anzeigen
        Also verändern geht immer…
        Ich glaube, da muss mal jemand mit deinen Eltern sprechen

        Kommentar


        • #19
          Zitat von jack88 Beitrag anzeigen
          Ja ist schon klar, aber wieso sollte sich ausgerechnet die Cipher-Klasse mit solchen Fragen beschäftigen und quasi vom Haus aus dem Client "Sicherheitsmechanismen" aufdrängen bzw. Funktionalität vorenthalten, die dieser möglicherweise entweder nicht benötigt oder gut gebrauchen könnte? Liegt der richtige Umgang mit dem Cipher-Objekt nicht in der Verantwortung des Clients? Oder soll das Cipher-Objekt den Client vor sich selbst beschützen auch wenn es nicht die geringste Ahnung haben kann in welchem Kontext es benutzt wird?
          Wenn Du einmal in einem Projekt ausschließlich mit Objekten arbeitest, deren Zustand Du nach der Initialisierung nicht mehr verändern kannst, merkst Du, dass Du sehr viel Komplexität und damit eben Fehlerquellen aus Deinem Projekt rausgekickt hast. Probier es einfach mal aus, das ist wirklich interessant. Und nicht abschrecken lassen, davon, dass viele gewohnte Wege auf die Art nicht mehr richtig funktionieren.

          Natürlich kann man solchen Klassen auch Methoden verpassen, die Properties ändern sollen (setFoo()), aber diese Setter ändern keine Properties der eigenen Instanz, sondern geben ein neu erstellte Objekt mit dem gewünschten Status zurück. Das Konzept kommt natürlich aus der funktionalen Programmierung, daher vermutlich der Hinweis auf Scala.

          Code:
          public method setB(int $b): ThisClass
          {
            return new ThisClass($this->a, $b, $this->c);
          }

          Kommentar


          • #20
            Zitat von bfenske
            Das Konzept kommt natürlich aus der funktionalen Programmierung, daher vermutlich der Hinweis auf Scala.
            Ja, quasi. Da es in funktionalen Sprachen eigentlich keine Objekte gibt, ist das nur halb richtig. Aber ja, unter anderem deswegen schien mir der Hinweis auf Scala angebracht.

            Zitat von bfenske
            Code:
            public method setB(int $b): ThisClass
            {
              return new ThisClass($this->a, $b, $this->c);
            }
            Eigentlich besser return static(...), aber passt schon.


            Kommentar

            Lädt...
            X