Namespace Separator \

**combie** · 08.12.2008, 17:06

Der . ist in PHP leider schon zur Stringverkettung vergeben. Und damit wäre klasse.methode die Verkettung zweier Konstanten. Auch nicht schöner.

**phpguru42** · 08.12.2008, 17:12

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 "::"?

**asp2php** · 08.12.2008, 17:26

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

**Griecherus** · 08.12.2008, 17:40

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

**combie** · 08.12.2008, 19:21

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.

**onemorenerd** · 08.12.2008, 22:10

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

**combie** · 08.12.2008, 22:43

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

**asp2php** · 08.12.2008, 22:45

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

**PHP-Desaster** · 08.12.2008, 23:07

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

**Griecherus** · 09.12.2008, 14:41

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

**asp2php** · 09.12.2008, 14:44

Abstimmen Leute

Ich bin für €

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

**Griecherus** · 09.12.2008, 14:57

PHP-Code:


namespace Foo~Bar~Baz;

ist doch auch wunderschön

Obwohl ich gestehen muss, dass dein Argument für € wirklich überzeugend ist

**PHP-Desaster** · 09.12.2008, 15:25

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

**combie** · 09.12.2008, 15:44

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"
₩

Namespace Separator \