php-resource



Zurück   PHP-Scripte PHP-Tutorials PHP-Jobs und vieles mehr > Sonstiges > Off-Topic Diskussionen
 

Login

 
eingeloggt bleiben
star Jetzt registrieren   star Passwort vergessen
 

 

 


Off-Topic Diskussionen Kein Platz für Deine Frage gefunden? Dann bist Du hier genau richtig!

Antwort
 
LinkBack Themen-Optionen Thema bewerten
  #1 (permalink)  
Alt 08-12-2008, 16:59
phpguru42
 Newbie
Links : Onlinestatus : phpguru42 ist offline
Registriert seit: Oct 2008
Beiträge: 71
phpguru42 ist zur Zeit noch ein unbeschriebenes Blatt
Standard 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:

Zitat:
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?
Mit Zitat antworten
  #2 (permalink)  
Alt 08-12-2008, 17:06
combie
 PHP Expert
Links : Onlinestatus : combie ist offline
Registriert seit: May 2006
Beiträge: 3.296
combie wird schon bald berühmt werden
Standard

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
Mit Zitat antworten
  #3 (permalink)  
Alt 08-12-2008, 17:12
phpguru42
 Newbie
Links : Onlinestatus : phpguru42 ist offline
Registriert seit: Oct 2008
Beiträge: 71
phpguru42 ist zur Zeit noch ein unbeschriebenes Blatt
Standard

Zitat:
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 "::"?
Mit Zitat antworten
  #4 (permalink)  
Alt 08-12-2008, 17:26
asp2php
 Banned
Links : Onlinestatus : asp2php ist offline
Registriert seit: Feb 2004
Beiträge: 11.745
asp2php ist zur Zeit noch ein unbeschriebenes Blatt
Standard

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
Mit Zitat antworten
  #5 (permalink)  
Alt 08-12-2008, 17:40
Griecherus
 PHP Senior
Links : Onlinestatus : Griecherus ist offline
Registriert seit: May 2005
Ort: Berlin
Beiträge: 1.036
Griecherus ist zur Zeit noch ein unbeschriebenes Blatt
Standard

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
Mit Zitat antworten
  #6 (permalink)  
Alt 08-12-2008, 19:21
combie
 PHP Expert
Links : Onlinestatus : combie ist offline
Registriert seit: May 2006
Beiträge: 3.296
combie wird schon bald berühmt werden
Standard

Zitat:
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
Mit Zitat antworten
  #7 (permalink)  
Alt 08-12-2008, 22:10
Benutzerbild von onemorenerd onemorenerd
  Moderator
Links : Onlinestatus : onemorenerd ist offline
Registriert seit: Mar 2005
Ort: Berlin
Beiträge: 9.471
onemorenerd wird schon bald berühmt werdenonemorenerd wird schon bald berühmt werden
Standard

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
Mit Zitat antworten
  #8 (permalink)  
Alt 08-12-2008, 22:43
combie
 PHP Expert
Links : Onlinestatus : combie ist offline
Registriert seit: May 2006
Beiträge: 3.296
combie wird schon bald berühmt werden
Standard

Zitat:
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
__________________
Wir werden alle sterben

Geändert von combie (08-12-2008 um 22:55 Uhr)
Mit Zitat antworten
  #9 (permalink)  
Alt 08-12-2008, 22:45
asp2php
 Banned
Links : Onlinestatus : asp2php ist offline
Registriert seit: Feb 2004
Beiträge: 11.745
asp2php ist zur Zeit noch ein unbeschriebenes Blatt
Standard

PHP-Code:
use F3FLOW3 as f;
use 
F3FLOW3MVCController as c;


class 
RequestHandlingController extends cAbstractController {
    protected 
$supportedRequestTypes = array('f\MVC\Web\Request');
    public function 
__construct(fObjectFactoryInterface $objectFactory
fPackageManagerInterface $packageManager) {
        
$this->arguments $objectFactory->create('c\Arguments');
        
parent::__construct($objectFactory$packageManager); 
Mit Zitat antworten
  #10 (permalink)  
Alt 08-12-2008, 23:07
PHP-Desaster
 PHP Expert
Links : Onlinestatus : PHP-Desaster ist offline
Registriert seit: Mar 2006
Beiträge: 3.105
PHP-Desaster befindet sich auf einem aufstrebenden Ast
Standard

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...
Mit Zitat antworten
  #11 (permalink)  
Alt 09-12-2008, 14:41
Griecherus
 PHP Senior
Links : Onlinestatus : Griecherus ist offline
Registriert seit: May 2005
Ort: Berlin
Beiträge: 1.036
Griecherus ist zur Zeit noch ein unbeschriebenes Blatt
Standard

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
Mit Zitat antworten
  #12 (permalink)  
Alt 09-12-2008, 14:44
asp2php
 Banned
Links : Onlinestatus : asp2php ist offline
Registriert seit: Feb 2004
Beiträge: 11.745
asp2php ist zur Zeit noch ein unbeschriebenes Blatt
Standard

Abstimmen Leute

Ich bin für €

Begründung: Da PHP schon immer mit $ zu tun hat, wird's langsam Zeit, dass € in Spiel kommt
Mit Zitat antworten
  #13 (permalink)  
Alt 09-12-2008, 14:57
Griecherus
 PHP Senior
Links : Onlinestatus : Griecherus ist offline
Registriert seit: May 2005
Ort: Berlin
Beiträge: 1.036
Griecherus ist zur Zeit noch ein unbeschriebenes Blatt
Standard


PHP-Code:
namespace Foo~Bar~Baz
ist doch auch wunderschön Obwohl ich gestehen muss, dass dein Argument für € wirklich überzeugend ist
Mit Zitat antworten
  #14 (permalink)  
Alt 09-12-2008, 15:25
PHP-Desaster
 PHP Expert
Links : Onlinestatus : PHP-Desaster ist offline
Registriert seit: Mar 2006
Beiträge: 3.105
PHP-Desaster befindet sich auf einem aufstrebenden Ast
Standard

Dann würde ich sagen, jedes frei wählbare Währungszeichen ist erlaubt.
Mit Zitat antworten
  #15 (permalink)  
Alt 09-12-2008, 15:44
combie
 PHP Expert
Links : Onlinestatus : combie ist offline
Registriert seit: May 2006
Beiträge: 3.296
combie wird schon bald berühmt werden
Standard

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"
__________________
Wir werden alle sterben

Geändert von combie (09-12-2008 um 15:58 Uhr)
Mit Zitat antworten
Antwort

Lesezeichen


Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
 

Themen-Optionen
Thema bewerten
Thema bewerten:

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are an


PHP News

ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlicht
ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlichtDie bekannte Marktplatzsoftware ebiz-trader ist in der Version 7.5.0 veröffentlicht worden.

28.05.2018 | Berni

Wissensbestand in Unternehmen
Wissensbestand in UnternehmenLebenslanges Lernen und Weiterbilden sichert Wissensbestand in Unternehmen

25.05.2018 | Berni


 

Aktuelle PHP Scripte

PHP Server Monitor

PHP Server Monitor ist ein Skript, das prüft, ob Ihre Websites und Server betriebsbereit sind.

11.09.2018 Berni | Kategorie: PHP/ Security
PHP WEB STATISTIK ansehen PHP WEB STATISTIK

Die PHP Web Statistik bietet Ihnen ein einfach zu konfigurierendes Script zur Aufzeichnung und grafischen und textuellen Auswertung der Besuchern Ihrer Webseite. Folgende zeitlichen Module sind verfügbar: Jahr, Monat, Tag, Wochentag, Stunde Folgende son

28.08.2018 phpwebstat | Kategorie: PHP/ Counter
Affilinator - Affilinet XML Produktlisten Skript

Die Affilinator Affilinet XML Edition ist ein vollautomatisches Skript zum einlesen und darstellen der Affili.net (Partnerprogramm Netzwerk) Produktlisten und Produktdaten. Im Grunde gibt der Webmaster seine Affilinet PartnerID ein und hat dann unmittelb

27.08.2018 freefrank@ | Kategorie: PHP/ Partnerprogramme
 Alle PHP Scripte anzeigen

Alle Zeitangaben in WEZ +2. Es ist jetzt 15:33 Uhr.