Namespace Separator \

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

  • Namespace Separator \

    Wusstet ihr das schon, dass der Separator für namespaces von "::" auf "\" geändert wurde? Im englischen Manual ist es schon aktualisiert.

    Naja, immer noch besser als wie vorgeschlagen ein Smilie ":>", "" oder "^^".
    http://wiki.php.net/rfc/namespaceseparator

    Im Heise-Forum auf die Frage "Was ist denn am \ so schlimm?", meinte jemand nur:

    Java:
    Attribute/Method access: foo.bar
    Static method access: Foo.bar
    Package access: foo.bar.baz

    C#:
    Attribute/Method access: foo.bar
    Static method access: Foo.bar
    Namespace access: foo.bar.baz

    Python:
    Attribute/Method access: foo.bar
    Static method access: Foo.bar
    Module access: foo.bar.baz

    PHP:
    Attribute/Method access: $foo->bar
    Static method access: Foo::bar
    Namespace access: foo\bar\baz
    PHP ist da wirklich nicht konsequent
    Was meint ihr dazu?

  • #2
    Der . ist in PHP leider schon zur Stringverkettung vergeben. Und damit wäre klasse.methode die Verkettung zweier Konstanten. Auch nicht schöner.
    Wir werden alle sterben

    Kommentar


    • #3
      Original geschrieben von combie
      Der . ist in PHP leider schon zur Stringverkettung vergeben.
      Ja klar, es geht aber eher darum, warum es nicht einheitlich (halbwegs) gehandhabt wird. Also warum nicht "::"?

      Kommentar


      • #4
        Tja, da hat jemand nicht gründlich bei der Entwicklung von PHP durchdacht ... den Punkt anstatt + als Stringverkettungsoperator zu nehmen ist doch irgendwie doof ... andererseits, warum sie nicht einfach die Kombination "->" konsequent weiter nutzen ist mir auch ein Rätsel

        Kommentar


        • #5
          Konsequenz bzw. Konsistenz gerade bei der Benamung (und nicht nur da) scheint ja leider noch nie PHPs Stärke gewesen zu sein, was sehr schade ist.
          Je länger ich damit arbeite, desto mehr störe ich mich an Kleinigkeiten wie die uneinheitliche Benennung der Funktionen, die Parametrisierung etc. pp.


          Grüße
          Nieder mit der Camel Case-Konvention

          Kommentar


          • #6
            Also warum nicht "::"?
            Das ist offensichtlich wenn du dir die Auflösungsregeln für Namespaces angesehen hast. Die haben sich jetzt drastisch vereinfacht.
            Ob \ jetzt wirklich gut ist ist, KA.
            Aber besser als :: alle male.
            Wir werden alle sterben

            Kommentar


            • #7
              Ich hätte es bei :: belassen. Das Ding ist schon als Scope Resolution Operator bekannt, das hätte also prima gepaßt.

              Der Konflikt und Auslöser für die Diskussion um einen anderen Namespace Separator als :: ist doch dieser:
              PHP-Code:
              namespace Foo;
              function 
              Bar() { ... }

              namespace {
              class 
              Foo {
                  function 
              Bar() { ... }
              }
              }

              Foo::Bar(); 
              Es gibt eine Funtion Bar im Namespace Foo und eine Methode Bar der Klasse Foo im globalen Namespace. Jetzt weiß der Interpreter bei Foo::Bar() nicht, was gemeint ist.

              Die naheliegende Lösung: Eine Vorzugsregel. Erstmal ::Foo::Bar() versuchen, dann Foo::Bar(), dann Fehler werfen. Nachteil: Zusätzliche Lookups kosten Performance.

              Auch eine Lösung: Aufrufe im globalen NS müssen als ::Foo::Bar() geschrieben werden. Nachteil: Nicht rückwärtskompatibel.


              Die Argumente in o.g. RFC finde ich größtenteils ziemlich daneben.

              1. type-ability
              Das ist abhängig vom OS und Tastaturlayout. Shift und zweimal ":" geht bei mir zackzack. Für ein \ muss ich genauso viele Tasten drücken, mir aber ziemlich die Hand verbiegen. Ich habe nämlich einen Mac. Wären die PHP-Entwickler alle Maccies, hätten wir jetzt :: oder was? Ein echt schwaches Argument!

              2. typo-vulnerability
              Mir fällt nichts ein, was man statt :: schreiben könnte, um validen, aber semantisch verschiedenen Code zu erhalten. Bei \ fällt es mir leichter:
              namespace "my\test"; => namespace 'my[tab]test';
              (Darf eigentlich ein Tab im Namen eines Namespace vorkommen?)

              3. parse-ability
              Okay, bei \a\b\c::d kann ich sehen, dass es ein NS, ein Sub-NS und Klassenkonstante ist. Bei a::b::c::d müßte ich auch die Variante NS, Sub-NS, Sub-NS, Konstante in Betracht ziehen. Das ist es ja genau, warum der Interpreter zusätzliche Lookups machen müßte. Insofern ein schwerwiegendes Argument!
              Dennoch habe ich etwas entgegenzusetzen: Ich finde Code voller \ unlesbar. Hier mal ein reales Beispiel, absichtlich nicht in PHP-Tags:
              Code:
              class RequestHandlingController extends F3\FLOW3\MVC\Controller\AbstractController {
              	protected $supportedRequestTypes = array('F3\FLOW3\MVC\Web\Request');
              	public function __construct(F3\FLOW3\Object\FactoryInterface $objectFactory, 
              F3\FLOW3\Package\ManagerInterface $packageManager) {
              		$this->arguments = $objectFactory->create('F3\FLOW3\MVC\Controller\Arguments');
              		parent::__construct($objectFactory, $packageManager);
              	}
              4. IDE compatibility
              Das ist fast das gleiche Argument wie das dritte! Eine IDE hat zwar keine Laufzeitinformationen (Hash Tables), aber das stört doch jetzt schon keinen (dynamische Funktionen/Variablen).

              5. number of chars
              Das ist das gleiche Argument wie das erste! Der andere Aspekt ist nämlich, dass der Parser ein \ schneller verarbeitet als ein ::. Aber darum ging es den Autoren garantiert nicht, sonst hätten wir is_num() statt is_numeric() usw.


              Es ist also eigentlich nur Argument 3 von Bedeutung. Lesbarkeit ist subjektiv, lassen wir das mal beseite. Die Doppeldeutigkeit von Foo::Bar() muss beseitigt werden. Entweder mit ::Foo::Bar() oder durch Verwendung von -> als Scope Resolution Operator in seiner bisherigen Form.
              Aber beides ist nicht rückwärtskompatibel und das ist es, wovor die Core-Entwickler offenbar Angst haben. (Ich sage nur register_globals...)
              Diese Angst beruht im Grunde auf einer Fehleinschätzung der Community. Sie ist nicht das, was die Core-Entwickler denken. Das zu erörtern, würde den Rahmen sprengen, jedoch ist diese Fehleinschätzung inzwischen der Hauptgrund für die verquere Fortentwicklung der Sprache.


              Der jetzt zur Diskussion stehende Fehler wurde imhho schon bei der Einführung des ::-Operators gemacht. Man hätte sich erstmal ein Konzept für die Sprache überlegen sollen (meinetwegen einfach abschauen bei anderen Sprachen). Auch wenn man dann nicht gleich alles implementiert hätte, zumindest die Notwendigkeit von Visibility Modifiers, static, final und eben Namespaces hätte man sehen sollen und sich die Wege offenhalten müssen. Der jetzt kommende \-Separator ist Ausdruck der Ziellosigkeit und mangelnden Struktur in der Entwicklung von PHP.


              Aber bei allem Für und Wider - ich kann auch mit \ leben. Ich bin PHP-Entwickler, ich bin Schräglichkeiten gewohnt.

              my 2 cents

              Kommentar


              • #8
                ich kann auch mit \ leben. Ich bin PHP-Entwickler, ich bin Schräglichkeiten gewohnt.
                Das kann ich nur unterschreiben!

                5.3 ist noch in der alpha Phase. Da sind Änderungen schon noch OK!
                Schlimmer wäre es, wenn sie es irgendwo um Version 6.3 über den Haufen geworfen hätten, wenn schon massig Produktions Code läuft.



                Code:
                use F3\FLOW3 as f;
                use F3\FLOW3\MVC\Controller as c;
                
                
                class RequestHandlingController extends c\AbstractController 
                {
                  protected $supportedRequestTypes = array('f\MVC\Web\Request');
                  public function __construct(f\Object\FactoryInterface $objectFactory, 
                f\Package\ManagerInterface $packageManager) 
                {
                    $this->arguments = $objectFactory->create('c\Arguments');
                   parent::__construct($objectFactory, $packageManager);
                  }
                }
                HI HI
                Das Forum muß überarbeitet werden!
                Der PHP Syntaxerleuchter mag die \ nicht

                PS:
                Alt: http://www.php.net/manual/de/languag...aces.rules.php
                Neu: http://www.php.net/manual/en/languag...aces.rules.php
                Zuletzt geändert von combie; 08.12.2008, 22:55.
                Wir werden alle sterben

                Kommentar


                • #9
                  PHP-Code:
                  use F3\FLOW3 as f;
                  use 
                  F3\FLOW3\MVC\Controller as c;


                  class 
                  RequestHandlingController extends c\AbstractController {
                      protected 
                  $supportedRequestTypes = array('f\MVC\Web\Request');
                      public function 
                  __construct(f\Object\FactoryInterface $objectFactory
                  f\Package\ManagerInterface $packageManager) {
                          
                  $this->arguments $objectFactory->create('c\Arguments');
                          
                  parent::__construct($objectFactory$packageManager); 

                  Kommentar


                  • #10
                    Ich habe mich ja inzwischen bei PHP auf einiges eingestellt, aber das ist ja mal krass ^^ Der Backslash ist doch wohl ein super-dösiges Trennzeichen für Namensräume. Aus Performancegründen sicher nachvollziehbar, aber wie onemorenerd schon sagte, einfach inkonsequent. Und die Alternativvorschläge zum Backslash im RFC sind ja auch nicht berauschend. Naja, was soll man machen, so gehts ja jetzt wohl weiter voran...

                    Kommentar


                    • #11
                      Ich lasse mal sämtliche technischen Gesichtspunkte außen vor, wenn ich behaupte, dass der Backslash rein optisch (und über die Semantik ließe sich auch streiten) eine Zumutung ist. Ich find's echt grausig
                      Nieder mit der Camel Case-Konvention

                      Kommentar


                      • #12
                        Abstimmen Leute

                        Ich bin für €

                        Begründung: Da PHP schon immer mit $ zu tun hat, wird's langsam Zeit, dass € in Spiel kommt

                        Kommentar


                        • #13

                          PHP-Code:
                          namespace Foo~Bar~Baz
                          ist doch auch wunderschön Obwohl ich gestehen muss, dass dein Argument für € wirklich überzeugend ist
                          Nieder mit der Camel Case-Konvention

                          Kommentar


                          • #14
                            Dann würde ich sagen, jedes frei wählbare Währungszeichen ist erlaubt.

                            Kommentar


                            • #15
                              Dann sind die Koreaner ja fein raus...
                              Die haben in ihrem 8Bit Zeichensatz an Stelle des Backslash ihr Währungszeichen.
                              Ein waagerecht durchgestrichenes W für "Won"
                              Zuletzt geändert von combie; 09.12.2008, 15:58.
                              Wir werden alle sterben

                              Kommentar

                              Lädt...
                              X