Ankündigung

Einklappen
Keine Ankündigung bisher.

Goto in PHP6

Einklappen

Neue Werbung 2019

Einklappen
Dieses Thema ist geschlossen.
X
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #16
    Ah, irgendein Beispiel also...
    Code:
    int parse()
    {
        Token   tok;
    
    reading:
        tok = gettoken();
        if (tok == END)
            return ACCEPT;
    shifting:
        if (shift(tok))
            goto reading;
    reducing:
        if (reduce(tok))
            goto shifting;
        return ERROR;
    }
    I leave it as an exercise for the reader to rewrite this without using goto statements.
    Vielleicht findest Du, wo ich das her habe. Ansonsten kannst Du noch nach Anderhalb-Schleifen suchen.
    Ob und in welcher Form PHP ein goto bekommt oder nicht, bestimmen eh andere. Ich bezweifele, dass hier jemand Einfluss darauf hat. Und auf die typische goto "Diskussion" habe ich keinen Bock. Deshalb ist von meiner Seite hier Ende.

    Kommentar


    • #17
      @register_globals: ich habe goto bisher auch nicht vermisst und bin auch ohne Labels und Sprunganzahl etc. ausgekommen. Aber Labels können schon manchmal praktisch sein. Nur leider ist PHP noch ser modular, weshalb der ehemals sinnvolle Charakter von solchen Sachen vor allem in Anfängerkreisen schnell verloren geht. Ich denke, wenn PHP mehr objektorientiert wäre, dann fiele das wohl nicht mehr so ins Gewicht. Eine Weiterentwicklung in Richtung OOP fände ich zunächst auch viel sinnvoller, da stimme ich mit dir überein.
      Dass ein reserviertes Wort noch nicht direkt eine Implementierung heißt, ist vollkommen klar. Schau dir Java oder Pascal/Delphi an, dort gibt es einige Schlüsselwörter, die reserviert, aber noch nicht implementiert sind.
      Ich denke, der Overhead spielt für PHP zwar schon eine Rolle, aber warum verwendet man dann keine bereits kompilierten CGI-Lösungen?
      Naja. Ich denke mal, wir werden sehen, was kommt. Man muss es ja nicht benutzen. Ich hatte jedenfalls noch nicht das Bedürfnis danach.
      Refining Linux: “Performing Push Backups – Part 1: rdiff-backup

      Kommentar


      • #18
        - Ich versteh die Aufgabe des Skriptes nicht so ganz was schonmal das erste Problem von "goto" deutlich macht. - Scheinbar ist das ein Lexer oder Tokenizer, sowas schreibt man in PHP nicht, dafuer ist es viel zu langsam. IMHO ist das ein Beispiel mit das PHP ueberhaupt nicht konkurrieren muss. - Wie gesagt, "goto" geht in die Richtung prozeduraler Code. In PHP wuerde ich das mit einem Zustands-Pattern und einer normalen Klasse mit mindestens den 3 Methoden umsetzen, zugegeben braeuchte ich deutlich mehr Code, aber der Vergleich ist wieder unfair, weil PHP an sich schon einen Deklarationsoverhead (class, public function, protected, ..) hat, den du auch mit "goto" nicht wegbekommst.
        Ich bezweifele, dass hier jemand Einfluss darauf hat. Und auf die typische goto "Diskussion" habe ich keinen Bock. Deshalb ist von meiner Seite hier Ende.
        Als haettest du taeglich goto-Diskussionen .. Ich will ja jetzt nicht mit dem allseits beliebten "dir gehen ja nur die Argumente aus" kommen, aber ich glaub diesmal triffts. Ich les mir den Artikel trotzdem in den naechsten Tagen mal durch. PS: Gibts in diesem Forum sowas wie Zeilenumbrueche? nl2br()?
        "Mein Name ist Lohse, ich kaufe hier ein."

        Kommentar


        • #19
          Ja, du musst einfach einen Zeilenumbruch einfügen. Und statt " reicht es, wenn du " schreibst. Ist dann auch besser zu lesen.






          Siehst du? Zeilenumbrüche. :P
          Refining Linux: “Performing Push Backups – Part 1: rdiff-backup

          Kommentar


          • #20
            Klar ich schreib hier im Fliesstext HTML-Entities aus Zeilenumbruch geht immernoch nicht.
            "Mein Name ist Lohse, ich kaufe hier ein."

            Kommentar


            • #21
              Zitat von register_globals Beitrag anzeigen
              Ich les mir den Artikel trotzdem in den naechsten Tagen mal durch.
              Danach können wir vielleicht weiterdiskutieren.

              p.s.: Und dann sollten wir vielleicht erstmal klären, was jeder einzelne von dem Statement goto erwartet bzw damit verbindet. Vermutlich relativiert sich die Diskussion dann eh bis zur Überflüssigkeit.

              Kommentar


              • #22
                Ein goto in PHP wundert mich keineswegs, denn immerhin haben die PHP-Entwickler echt Talent, unsinnige Sprachkonstrukte einzuführen, wie z.B. __get, __set, __call - ist doch unmöglich zu dokumentieren, außerdem neigen so noch viel mehr Menschen dazu, von außen direkt auf Klasseneigenschaften zuzugreifen.

                Kommentar


                • #23
                  Wie willst du das MVC-Pattern ohne __call umsetzen? eval, call_user_func, ..? Dass es nicht dokumentierbar ist koennte man aendern, in dem man erlauben wuerde, virtuelle Eigenschaften auszuzeichnen. Entweder muessten da die Dokumentations-Tools vorlegen, oder PHP mit eigenen Sprachkonstrukten.
                  "Mein Name ist Lohse, ich kaufe hier ein."

                  Kommentar


                  • #24
                    Huch? Wieso erfordert das MVC-Pattern __call?

                    call_user_func verwende ich, sofern ich mit einem simplen Switch nicht weiterkommen (passiert sehr selten). Interfaces garantieren mir das Vorhandensein von gewissen Methoden. Im allerschlimmsten Falle gibt es dann immernoch Reflections.

                    Meine Programmierung setzt niemals auf seltsame PHP-Sprachkonstrukte, sondern folgt weitgehend den Möglichkeiten, wie es z.B. mit Java-Mitteln auch möglich ist. Aus meiner Erfahrung tragen die Magic Methods ausschließlich zur Faulheit der Entwickler bei.

                    Kommentar


                    • #25
                      Wie verarbeitest du denn dann eine Anfrage? (auch eine die fehlschlaegt, Fallbacks, ..)

                      (ich mein die Frage ernst, nicht um gleich besserwisserisch zu kontern )
                      "Mein Name ist Lohse, ich kaufe hier ein."

                      Kommentar


                      • #26
                        Welches Problem willst Du dabei konkret mit __call lösen?
                        __get/__set gefallen mir in dieser Form nicht sonderlich. Zentralisierte Eigenschaftenschleuder. Vielleicht sehe ich den Vorteil einfach nur nicht.
                        Bei __call() schwanke ich noch. Schon allein, weil mir spontan etwas (wenn man das will) sinnvolles einfällt, für das ich sonst in PHP keine Lösung kenne.
                        PHP-Code:
                        public function __call($fn$p)
                        {
                          if (!
                        method_exists($this$fn))
                          {
                            throw new ....;
                          }

                        (das method_exists() kann man sich da sogar sparen? Wenn php __call() aufruft, gibt es wohl keine entsprechende public function.)

                        Kommentar


                        • #27
                          Was meinst du genau? Das Mapping von URL-Parameter auf Methoden (also quasi Actions im Sinne von Zend)?
                          a) Ich rufe keine Methoden auf, die nicht in Interfaces definiert sind.
                          b) Wenns um rein dynamische Aufrufe geht, überprüfe ich vorher, ob die Methode existiert (mit __call sollte man das auch machen). Im Falle von false, gibt es einen im Interface definierte Fallback-Methode.

                          Ich halte es schlichtweg für falsch, __call/__get als Fallback anzusehen. Wenn man sowas brauch, hats der Programmierer mächtig verbockt und das ist einer der Mitgründe, warum für mich das Zend-Framework so ein zweischneidiges Schwert ist.

                          EDIT: David, du warst schneller.
                          Ich mache es im Prinzip ähnlich, ohne __call:
                          PHP-Code:
                          Interface Action
                          {
                              public function 
                          dispatcher($action);
                          }

                          Class 
                          SampleAction implements Action
                          {
                              public function 
                          dispatcher($action)
                              {
                                  if(
                          method_exists($this$action)) {
                                      
                          call_user_func(array($this$action));
                                  } else {
                                      throw new 
                          Exception('Dispatching failed');
                                  }
                              }

                          EDIT 2: Die Reflection-API von PHP ist auch eine nette Sache.

                          Kommentar


                          • #28
                            Wobei ich das Abbilden von zusätzlicher Funktionalität auf bestehende/bekannte Sprachkonstrukte nicht pauschal schlecht finde. Gerade wenn dadurch die Lesbarkeit erhöht wird. An so etwas wie
                            Code:
                            class Foo
                            {
                              protected double seconds = 0;
                              public double hours
                              {
                                get { return seconds / 3600; }
                                set { seconds = value * 3600; }
                              }
                            }
                            
                            Foo f = new X();
                            f.hours = 3;
                            bin gewöhnt und mag es nicht mehr missen - obwohl es unter der Haube auch das gleiche Zeugs ist, was schon VB gemacht hat (nämlich doch Methoden und -aufrufe zu erzeugen).

                            Kommentar


                            • #29
                              Zitat von Quadaptor-new Beitrag anzeigen
                              Was meinst du genau? Das Mapping von URL-Parameter auf Methoden (also quasi Actions im Sinne von Zend)?
                              a) Ich rufe keine Methoden auf, die nicht in Interfaces definiert sind.
                              b) Wenns um rein dynamische Aufrufe geht, überprüfe ich vorher, ob die Methode existiert (mit __call sollte man das auch machen). Im Falle von false, gibt es einen im Interface definierte Fallback-Methode.

                              Ich halte es schlichtweg für falsch, __call/__get als Fallback anzusehen. Wenn man sowas brauch, hats der Programmierer mächtig verbockt und das ist einer der Mitgründe, warum für mich das Zend-Framework so ein zweischneidiges Schwert ist.

                              EDIT: David, du warst schneller.
                              Ich mache es im Prinzip ähnlich, ohne __call:
                              PHP-Code:
                              Interface Action
                              {
                                  public function 
                              dispatcher($action);
                              }

                              Class 
                              SampleAction implements Action
                              {
                                  public function 
                              dispatcher($action)
                                  {
                                      if(
                              method_exists($this$action)) {
                                          
                              call_user_func(array($this$action));
                                      } else {
                                          throw new 
                              Exception('Dispatching failed');
                                      }
                                  }

                              EDIT 2: Die Reflection-API von PHP ist auch eine nette Sache.
                              Hm das sieht in der Tat auch gut aus, aber ich muss zu meiner Schande zugeben: Ich hatte nie wirklich Probleme mit __get/__set/__call Der Nachteil ist ja lediglich, dass die Auszeichnung fehlt und der Editor keine Vorschlaege macht, aber wie soll man das Problem auch loesen, wenn es um dynamische Eigenschaften geht - sie nicht verwenden ist halt ein schoenes Ziel, aber es kann auch enorm einschraenken.
                              "Mein Name ist Lohse, ich kaufe hier ein."

                              Kommentar


                              • #30
                                Zitat von Chriz Beitrag anzeigen
                                Wie willst du das MVC-Pattern ohne __call umsetzen? eval, call_user_func, ..? Dass es nicht dokumentierbar ist koennte man aendern, in dem man erlauben wuerde, virtuelle Eigenschaften auszuzeichnen. Entweder muessten da die Dokumentations-Tools vorlegen, oder PHP mit eigenen Sprachkonstrukten.
                                Das Problem an deiner Aussage ist, dass du offensichtlich nur die MVC-Implementierung von Zend & Co. gesehen hast. Dabei ist das Problem nicht MVC, denn das ist ein Pattern, das genau für eine Aufgabenstellung definiert ist, sondern die Umsetzung der Request-Behandlung. Diese sieht ein "Routing" auf genau eine Action vor. Hierbei wird von der __call()-Methode deshalb Gebrauch gemacht um sich die konkrete Implementierung sparen und das Handling in die Laufzeit verlagern kann. Darüber hinaus bin ich der Meinung, dass die Umsetzung des MVC-Pattern auf Grund der Definition von "Model" in den Frameworks wie Zend, CakePHP und CodeIgniter nicht ganz der Definition entsprechen...

                                Eine andere Umsetzung des MVC-Pattern in Verbindung mit dem PageController beinhaltet das Adventure PHP Framework (kurz: APF). Dieses geht davon aus, dass jeder GUI-Knoten ein eigener MVC-Knoten ist, der durch die entsprechend im Pattern beschriebenen Teile repräsentiert wird. Der PageController verarbeitet diesen dann mit Hilfe des MVC-Controllers. Da das Ganze auch für beliebig tiefe Strukturen funktioniert, spricht man dabei auch vom HMVC-Pattern. Schaust du dir den Quellcode an, so setze ich nicht einmal __call(), __get(), __set() oder andere unsinnige Konstrukte ein. Dieses Konzept funktioniert sogar in PHP 4 per excellance. Letztere "magische" Methoden verführen meiner Ansicht nach nur zur Bastelei, denn man muss sich beim Schreiben des Quellcodes keine Gedanken über die API machen.
                                Viele Grüße,
                                Dr.E.

                                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                1. Think about software design before you start to write code!
                                2. Discuss and review it together with experts!
                                3. Choose good tools (-> Adventure PHP Framework (APF))!
                                4. Write clean and reusable software only!
                                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

                                Kommentar

                                Lädt...
                                X