Goto in PHP6

[David]

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

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).

[Quadaptor]

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:

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.

[David]

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.

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.)

[Chriz]

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

(ich mein die Frage ernst, nicht um gleich besserwisserisch zu kontern )

[Quadaptor]

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.

[Chriz]

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.

[Quadaptor]

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.

[David]

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.

[Chriz]

Klar ich schreib hier im Fliesstext HTML-Entities aus Zeilenumbruch geht immernoch nicht.

[Manko10]

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

[Chriz]

- 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()?

[Manko10]

@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.

[David]

Ah, irgendein Beispiel also...

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.

[Chriz]

Du kannst nicht ein Argument nennen, dass fuer "goto" im direkten Vergleich zu Schleifen und Funktionen spricht?

[David]

(und ich fasse 41 Seiten jetzt nicht zusammen)