PHP Namespaces

[Verwijderd]

Hey,

Ik ben bezig met het bouwen van een PHP framework voor PHP 5.3 of hoger. Een van de nieuwe opties is de mogelijkheid tot het gebruik van namespaces.

Ik loop echter tegen een probleem aan, ik heb de namespace: "Framework\Library\System" met daarin de klasse "Load", die zo wordt aangeroepen: "Framework\Library\System\Load". Dit werkt opzich allemaal goed, maar nu komt het.
Ik wil natuurlijk niet elke keer opnieuw dat hele stuk schrijven als ik de Load class wil gebruiken, dus ik ga aan PHP vertellen dat ik een afkorting wil:
"use Framework\Library\System\Load as Load;"
Volgens de PHP-syntax compleet correct. Het werkt ook gewoon, echter, zodra ik deze "snelkoppeling" ga gebruiken in bestanden die via require_once ingeladen worden werkt deze niet meer, dat resulteert in de volgende fout: "Fatal error: Class 'Load' not found."

Heeft iemand ook last van dit probleem? Doe ik iets fout of is dit onhandig gebouwd door de makers van PHP?

Alvast bedankt!

[StM]

Als ik het goed heb is de scope van een namespace beperkt tot het ene bestand waar je in werkt aangezien het namespace systeem verwerkt wordt tijdens het parsen van de file. Je zal hem dus in iedere file opnieuw moeten aliassen gok ik.

[MueR]

Volgens de PHP Manual is de syntax net wat anders. Verder met ^^

[ Voor 7% gewijzigd door MueR op 12-02-2009 14:25 ]

[Verwijderd]

Site.to.Make schreef op donderdag 12 februari 2009 @ 14:23:
Als ik het goed heb is de scope van een namespace beperkt tot het ene bestand waar je in werkt aangezien het namespace systeem verwerkt wordt tijdens het parsen van de file. Je zal hem dus in iedere file opnieuw moeten aliassen gok ik.

Ja, dat de scope van de namespace beperkt is tot het ene bestand is logisch, maar het aliassen daarvan lijkt me juist iets wat niet beperkt zou moeten zijn? Een alias elke keer opnieuw invoeren lijkt me onnodig veel werkt.

MueR schreef op donderdag 12 februari 2009 @ 14:24:
Volgens de PHP Manual is de syntax net wat anders. Verder met ^^

Helaas, je kijkt in de oude manual, de :: is vervangen door \.
Zie: http://nl2.php.net/manual....namespaces.rationale.php

[ Voor 23% gewijzigd door Verwijderd op 12-02-2009 14:26 ]

[StM]

Het lijkt me vrij logisch aangezien je niet altijd dezelfde alias wil gebruiken. Anders had je beter een kortere namespace naam kunnen pakken.

Even een kleine offtopic vraag: Waarom ben je een framework aan het maken voor alpha software?

[Verwijderd]

Site.to.Make schreef op donderdag 12 februari 2009 @ 14:28:
Het lijkt me vrij logisch aangezien je niet altijd dezelfde alias wil gebruiken. Anders had je beter een kortere namespace naam kunnen pakken.

Even een kleine offtopic vraag: Waarom ben je een framework aan het maken voor alpha software?

Voor bepaalde, vaak voorkomende zaken als een load class, een config class, een registry class wil ik graag altijd dezelfde alias gebruiken. Bij andere classes hoeft dat niet altijd, vandaar mijn verbazing.

Offtopic: Omdat het niet lang meer duurt voordat de stabiele versie uit gaat komen en ik er dan graag snel bij wil zijn.

[StM]

Imo hadden aliasses niet eens erin hoeven te komen en ben blij dat ze niet gedeeld worden tussen bestanden. Je zal er dus niet aan ontkomen om ze of steeds te aliassen of ze bij hun volledige naam te roepen. (want imo de voorkeur heeft)

offtopic:
Dit komt doordat de PHP ontwikkelaars helaas weer eens de weg van de minste weerstand hebben kozen. Net zoals \ als seperator...

[Verwijderd]

Site.to.Make schreef op donderdag 12 februari 2009 @ 14:35:
Imo hadden aliasses niet eens erin hoeven te komen en ben blij dat ze niet gedeeld worden tussen bestanden. Je zal er dus niet aan ontkomen om ze of steeds te aliassen of ze bij hun volledige naam te roepen. (want imo de voorkeur heeft)

offtopic:
Dit komt doordat de PHP ontwikkelaars helaas weer eens de weg van de minste weerstand hebben kozen. Net zoals \ als seperator...

Hmm, oke, dan houd ik het bij de volle naam.

@ dat bold gedeelte, wat bedoel je met dit?
En de \ seperator... ja..Ik snap wat je bedoeld.

[StM]

offtopic:
Ze kunnen aliasses niet eens sharen om de simpele reden dat op het moment van parsen niet bekend is wat hun parent zal zijn. Daarnaast hebben ze de \ als seperator gekozen omdat die het simpelst de engine in te hacken was omdat die nog geen speciale functie had... Ze hadden syntaxtechnisch 100x beter :: of . ofzo kunnen pakken.

Vandaar dat ik zeg dat ze de weg van de minste weerstand gepakt hebben.

[Verwijderd]

Site.to.Make schreef op donderdag 12 februari 2009 @ 14:43:

offtopic:
Ze kunnen aliasses niet eens sharen om de simpele reden dat op het moment van parsen niet bekend is wat hun parent zal zijn. Daarnaast hebben ze de \ als seperator gekozen omdat die het simpelst de engine in te hacken was omdat die nog geen speciale functie had... Ze hadden syntaxtechnisch 100x beter :: of . ofzo kunnen pakken.

Vandaar dat ik zeg dat ze de weg van de minste weerstand gepakt hebben.

Ja, de :: lijkt mij ook veel netter en beter.. Maargoed, zal er toch niet komen..

[Janoz]

Persoonlijk vind ik het juist erg logisch dat de alias per bestand is. Zou je dit laten lekken dan is het complete nut van namespaces weer weg.

[ Voor 3% gewijzigd door Janoz op 12-02-2009 14:52 ]

[.oisyn]

Verwijderd schreef op donderdag 12 februari 2009 @ 14:26:
[...]

Ja, dat de scope van de namespace beperkt is tot het ene bestand is logisch, maar het aliassen daarvan lijkt me juist iets wat niet beperkt zou moeten zijn? Een alias elke keer opnieuw invoeren lijkt me onnodig veel werkt.

Ok so let me get this straight: De PHP ontwikkelaars implementeren (eindelijk) een langverwachte feature: namespaces. Custom prefixes zijn lelijk en en lastig, dus het is handig als je je identifiers kunt groeperen in een namespace zodat ze de lading kunnen blijven dekken zonder dat je conflicten krijgt.

Toen kwam IvoVB die dacht: hey wat een hippe feature. Nu kan ik eindelijk m'n identifiers goed ordenen. En weet je wat, laat ik meteen het hele nut van die namespaces overboord gooien door voor allerlei classes korte aliasen te maken in de global namespace, zodat ik daarna wederom in de knoei kom met m'n identifiers. Woei.

Nofi verder, maar wellicht dat dit enigszins verheldert waarom je dat wat jij wilt eigenlijk helemaal niet zou moeten willen . Ik moet er niet aan denken dat als ik eens wat 3rd party code importeer met require/include dat ik dan ineens allemaal troep in m'n namespace krijg omdat die library (terecht) allemaal aliasen gebruikt. Wat dat betreft ben ik het eindelijk een keer daadwerkelijk eens met een designkeuze van het PHP team .

Het is niet voor niets dat C# en Java dit ook niet ondersteunen en dat het gebruik van using directives en declarations in C++ headers enorm wordt afgeraden.

.edit @ janoz: je gebruikt veel te weinig woorden

[ Voor 9% gewijzigd door .oisyn op 12-02-2009 15:02 ]

[StM]

.oisyn schreef op donderdag 12 februari 2009 @ 14:58:
[...]

Ok so let me get this straight: De PHP ontwikkelaars implementeren (eindelijk) een langverwachte feature: namespaces. Custom prefixes zijn lelijk en en lastig, dus het is handig als je je identifiers kunt groeperen in een namespace zodat ze de lading kunnen blijven dekken zonder dat je conflicten krijgt.

Toen kwam IvoVB die dacht: hey wat een hippe feature. Nu kan ik eindelijk m'n identifiers goed ordenen. En weet je wat, laat ik meteen het hele nut van die namespaces overboord gooien door voor allerlei classes korte aliasen te maken in de global namespace, zodat ik daarna wederom in de knoei kom met m'n identifiers. Woei.

Nofi verder, maar wellicht dat dit enigszins verheldert waarom je dat wat jij wilt eigenlijk helemaal niet zou moeten willen . Ik moet er niet aan denken dat als ik eens wat 3rd party code importeer met require/include dat ik dan ineens allemaal troep in m'n namespace krijg omdat die library (terecht) allemaal aliasen gebruikt. Wat dat betreft ben ik het eindelijk een keer daadwerkelijk eens met een designkeuze van het PHP team .

Het is niet voor niets dat C# en Java dit ook niet ondersteunen en dat het gebruik van using directives en declarations in C++ headers enorm wordt afgeraden.

.edit @ janoz: je gebruikt veel te weinig woorden

Mijn idee alleen heel wat beter uitgelegd

[Verwijderd]

Hmm, ja van die kant had ik het nog niet bekeken, logisch natuurlijk. Bedankt!

[doeternietoe]

Site.to.Make schreef op donderdag 12 februari 2009 @ 14:43:

offtopic:
Ze kunnen aliasses niet eens sharen om de simpele reden dat op het moment van parsen niet bekend is wat hun parent zal zijn. Daarnaast hebben ze de \ als seperator gekozen omdat die het simpelst de engine in te hacken was omdat die nog geen speciale functie had... Ze hadden syntaxtechnisch 100x beter :: of . ofzo kunnen pakken.

Vandaar dat ik zeg dat ze de weg van de minste weerstand gepakt hebben.

offtopic:
Het was inderdaad misschien mooier geweest, maar PHP is natuurlijk een taal die langzaam zo gegroeid is, het was altijd al mogelijk om :: te gebruiken voor statische functies. Als je :: gebruikt voor namespaces, dan krijg je verwarring. Stel dat ik de function foo::bar::blaat() aanroep. Is dat dan de statische functie blaat in de class bar en de namespace foo of is het de functie blaat in de namespace foo::bar?

Ik vind het er ook niet uitzien, maarja, je moet wat. De punt was ook al in gebruik voor het samenvoegen van strings.

[frickY]

Site.to.Make schreef op donderdag 12 februari 2009 @ 14:43:
Ze hadden syntaxtechnisch 100x beter :: of . ofzo kunnen pakken.

Niet, want de :: is al bezet als static-operator, en de . als string concatenation. Speerpunt is backwards compatibility waardoor deze niet beschikbaar waren. Maar ben het er mee eens dat van alle overige opties de backslash nog wel de slechtste is. Mijn voorkeur was => geweest.

Verder sluit ik me aan bij .oisyn dat je het hele nut van namespaces een beetje overboord gooit als je ze allemaal alias-ed.

[.oisyn]

frickY schreef op donderdag 12 februari 2009 @ 19:16:
[...]

Niet, want de :: is al bezet als static-operator, en de . als string concatenation.

Doet er weinig toe. De grammatica hoeft niet context-vrij te zijn (is de PHP grammatica waarschijnlijk toch al niet), en je kunt aan de operands zien wat de betekenis van de operator is. De punt had prima gekunt, je weet op het moment van gebruik toch al dat de symbolen geen defines zijn maar namespaces (variabelen gaan sowieso niet op want die beginnen met een $). En dat de :: niet kan is al helemaal onzin, grammaticaal is het juist identiek aan class scope selection.

[ Voor 4% gewijzigd door .oisyn op 12-02-2009 19:21 ]

[Verwijderd]

doeternietoe schreef op donderdag 12 februari 2009 @ 19:04:
[...]

offtopic:
Het was inderdaad misschien mooier geweest, maar PHP is natuurlijk een taal die langzaam zo gegroeid is, het was altijd al mogelijk om :: te gebruiken voor statische functies. Als je :: gebruikt voor namespaces, dan krijg je verwarring. Stel dat ik de function foo::bar::blaat() aanroep. Is dat dan de statische functie blaat in de class bar en de namespace foo of is het de functie blaat in de namespace foo::bar?

Ik vind het er ook niet uitzien, maarja, je moet wat. De punt was ook al in gebruik voor het samenvoegen van strings.

offtopic:
Nou ja, dat is natuurlijk gewoon een kwestie van je klassen een duidelijke onderscheidende naam geven (zoals C prefix of iets dergelijks). De parser ziet ter plekke wel wat er precies mee bedoelt wordt en geeft bij een conflict een error. Deze manier vind ik esthetisch echt een gedrocht.

[orf]

.oisyn schreef op donderdag 12 februari 2009 @ 19:20:
[...]

De punt had prima gekunt, je weet op het moment van gebruik toch al dat de symbolen geen defines zijn maar namespaces (variabelen gaan sowieso niet op want die beginnen met een $).

PHP:

echo subnamespace\FOO; // resolves to constant Foo\Bar\subnamespace\FOO

Als er een punt gebruikt zou zijn zou je nu de 2 constanten geconcat outputten. Uit historische overweging wordt een ongedefinieerde constante (helaas) gevonverteerd naar een string. (Met een notice)

[Verwijderd]

orf schreef op donderdag 12 februari 2009 @ 19:33:

PHP:

echo subnamespace\FOO; // resolves to constant Foo\Bar\subnamespace\FOO

Als er een punt gebruikt zou zijn zou je nu de 2 constanten geconcat outputten. Uit historische overweging wordt een ongedefinieerde constante (helaas) gevonverteerd naar een string. (Met een notice)

Die compatibility is echt backwards als in achterlijk. Daar hadden ze juist meteen afstand van kunnen nemen. Ik gok dat het simpelweg problemen zou opleveren met de parser.

[orf]

Verwijderd schreef op donderdag 12 februari 2009 @ 19:41:
[...]

Die compatibility is echt backwards als in achterlijk. Daar hadden ze juist meteen afstand van kunnen nemen. Ik gok dat het simpelweg problemen zou opleveren met de parser.

En toch zie je het helaas veel te vaak; met name array keys worden door domme mensen vaak zonder quotes geschreven.

[--MeAngry--]

Op zich zou het wel een goede oplossing zijn om alle n00bs te verliezen, maar dan krijg je weer het probleem dat servers niet geupgrade worden omdat de scriptsoep van zo'n n00b niet meer draait en ze dus geen klanten meer krijgen...
Het is een verhaal zonder einde, en eigenlijk ook best offtopic.

Ik moet wel zeggen dat ik namespaces met luid gejuich verwelkom. Zeker in grote projecten waar objecten van een zelfde soort vaak meerdere malen voor kunnen komen, gaan namespaces voor veel verduidelijking zorgen, en hoef je geen ellenlange prefixes meer te gebruiken.

[Verwijderd]

Eigenlijk vind ik de keuze voor \ nog niet zo heel gek, het is natuurlijk wel wennen als je anders gewend bent uit andere talen, maar wat zijn eigenlijk de makkelijke alternatieven?

Dingen als => zijn alleen maar lastig en voor de rest worden ongeveer alle tekens op je toetsenbord gebruikt ergens voor, volgens mij bij een standaard toetsenbord alleen de ~ niet? Maar dat is al helemaal vaag..

± en § worden ook niet gebruikt lijkt me, maar dat zit niet op een standaard toetsenbord..

[Verwijderd]

Verwijderd schreef op donderdag 12 februari 2009 @ 20:12:
Eigenlijk vind ik de keuze voor \ nog niet zo heel gek, het is natuurlijk wel wennen als je anders gewend bent uit andere talen, maar wat zijn eigenlijk de makkelijke alternatieven?

Dingen als => zijn alleen maar lastig en voor de rest worden ongeveer alle tekens op je toetsenbord gebruikt ergens voor, volgens mij bij een standaard toetsenbord alleen de ~ niet? Maar dat is al helemaal vaag..

± en § worden ook niet gebruikt lijkt me, maar dat zit niet op een standaard toetsenbord..

Een makkelijker alternatief zou zijn om gewoon de :: operator te gebruiken, net als bijvoorbeeld C++. Naar mijn weten introduceren ze zo een nieuwe syntaxis om namespaces te definiëren. Nu kan dat vast geen kwaad als je louter in PHP programmeert, maar als je zoals vele ook hebt gewerkt met andere talen kan dit nogal wat verwarring veroorzaken.
Het is niet zo dat een operator maar een keer gebruikt kan worden, dus ik betreur dan ook de laksheid van het PHP-team om de :: operator hiervoor te implementeren. Of zie ik een zeer belangrijke reden waarom de \ is gebruikt over het hoofd?

[Verwijderd]

:: is al een operator in PHP 4 en 5.

[doeternietoe]

Maar wat is dan het probleem van de \ eigenlijk, behalve dat het lelijk is en in geen enkele andere taal zo gedaan wordt?

Imho had de punt inderdaad ook wel gemogen, hadden ze gelijk het naar een string casten van een undefined constante eruit kunnen wippen, weg conflict. Met de :: blijf je theoretisch conflicten houden tussen functies in een namespace en statische methoden van een class.

[Michali]

doeternietoe schreef op donderdag 12 februari 2009 @ 20:39:
Imho had de punt inderdaad ook wel gemogen, hadden ze gelijk het naar een string casten van een undefined constante eruit kunnen wippen, weg conflict.

Dan breken ze volgens mij veel sites / applicaties. Typisch voorbeeld van een feature die van eigenlijke bugs features maakt. Best vaak dat je nog tegenkomt dat men iets als $foo[bar] doet, dus zonder quotes. Walgelijk, maar het gebeurt wel.

[.oisyn]

Verwijderd schreef op donderdag 12 februari 2009 @ 20:34:
:: is al een operator in PHP 4 en 5.

Anders herhaal je een al ontkrachte post uit eerder in deze draad.

Die "operator" waar jij het over hebt verandert met namespaces helemaal niet van betekenis. Namespace scope selection (met "namespace" als de globale betekenis van het woord, niet die specifieke PHP feature)

Class::member, Namespace::Class, Namespace::Class::member... allemaal hetzelfde. Werkt in C++ ook zo, zonder ambiguïteiten. Ik zie het probleem niet.

doeternietoe schreef op donderdag 12 februari 2009 @ 20:39:
Met de :: blijf je theoretisch conflicten houden tussen functies in een namespace en statische methoden van een class.

Wat zijn die conflicten dan precies? Laat eens een stukje code zien waarbij het ambigu is zou ik zeggen. Gewoon maar blind roepen dat hij al *ergens* voor gebruikt wordt is een non-argument.

orf schreef op donderdag 12 februari 2009 @ 19:33:
[...]

PHP:

echo subnamespace\FOO; // resolves to constant Foo\Bar\subnamespace\FOO

Als er een punt gebruikt zou zijn zou je nu de 2 constanten geconcat outputten. Uit historische overweging wordt een ongedefinieerde constante (helaas) gevonverteerd naar een string. (Met een notice)

Maar wat gebeurt er nu in PHP 5.3 als je Foo.Bar doet terwijl Foo een namespace is en Bar een class? Krijg je dan ook de string "FooBar" of een compile error? Ik mag hopen dat laatste. En als dat zo is, dan kan je hele argument de deur uit. Backwards-compatibility gaat alleen op voor ongedefiniëerde identifiers. Als het namespaces zijn dan zijn ze niet meer ongedefiniëerd. De . als namespace scope kan dus prima naast concatenatie leven. Grammaticaal wordt het wellicht wat lastiger (itt de :: die grammaticaal exact hetzelfde is als wat het nu al is), maar ik geloof dat er sowieso geen formele grammatica bestaat voor PHP, noch dat ze gebruik maken parser generator.

.edit: net even getest:

Notice: Use of undefined constant Foo - assumed 'Foo' in C:\php5.3\tests\ns.php on line 5
Notice: Use of undefined constant Bar - assumed 'Bar' in C:\php5.3\tests\ns.php on line 5
FooBar

Dus ik dacht: hmmm, hij zoekt nog wel naar constants... Even proberen:

PHP:

namespace Foo\Bar;

define("Foo", 34);
define("Bar", 12);

echo Foo.Bar;

Output 3412

En het wordt nog leuker:

PHP:

namespace A;

class Foo
{
    function Bar() { echo "Foo::Bar()\n"; }
}

namespace A\Foo;

function Bar() { echo "Foo\Bar()\n"; }


namespace A;

Foo::Bar();
Foo\Bar();

Raad eens wat dat output Mijn god wat lelijk zeg. Nee, idd, op die manier kun je de :: ook niet meer gebruiken nee

Blijkbaar leeft alles sowieso al in z'n eigen namespace:

PHP:

namespace A\Foo;

namespace A;
define("Foo", "constant Foo");
class Foo { function __tostring() { return "class Foo"; } };
function Foo() { return "function Foo()"; }

echo Foo, "\n";
echo new Foo(), "\n";
echo Foo(), "\n";

constant Foo
class Foo
function Foo()

[ Voor 140% gewijzigd door .oisyn op 12-02-2009 22:14 ]

[doeternietoe]

.oisyn schreef op donderdag 12 februari 2009 @ 21:36:
Wat zijn die conflicten dan precies? Laat eens een stukje code zien waarbij het ambigu is zou ik zeggen. Gewoon maar blind roepen dat hij al *ergens* voor gebruikt wordt is een non-argument.

PHP:

namespace bar;

function foo(){
  echo 'A';
}

class bar{
  public function foo(){
    echo 'B';
  }
}

en

PHP:

bar::foo();

Is de output nu A of B?

Natuurlijk hadden de ontwikkelaars er ook voor kunnen kiezen om één van de twee expliciet voorrang te geven of functies überhaubt geen deel uit te laten maken van de namespaces.

En dat de code lelijk is, maakt niet uit. In principe heb je een conflict.

[ Voor 5% gewijzigd door doeternietoe op 12-02-2009 22:21 ]

[.oisyn]

doeternietoe schreef op donderdag 12 februari 2009 @ 22:20:
[...]

PHP:

namespace bar;

function foo(){
  echo 'A';
}

class bar{
  public function foo(){
    echo 'B';
  }
}

en

PHP:

bar::foo();

Is de output nu A of B?

Dat ligt aan de context. Als je in de global namespace zit, dan 'A', want in de global namespace bestaat er alleen een 'bar' namespace.
Zit je in de namespace 'bar' zelf, dan is het 'B', want het enige dat 'bar' heet in de 'bar' namespace is die class. Mijn voorbeeld van daarnet was beter:

PHP:

namespace A; // dummy namespace, het lijkt niet mogelijk om na de namespace weer naar de global te gaan

namespace A\bar;
function foo() { echo 'A'; }

namespace A;
class bar { function foo() { echo 'B'; } }

bar::foo();

Nu is het ambigu. Ik ging er niet vanuit dat je allemaal verschillende dingen met dezelfde naam mocht definieren in PHP, zoals dat in andere talen ook niet mag. Blijkbaar pakt PHP dit anders aan en heeft ieder 'ding' sowieso z'n eigen namespace. Een namespace-naam conflicteert dus nooit met een constante, functie of klassenaam. Geen enkel ding conflicteert ooit met een ander type ding.

Als je dat design aanhoudt kun je idd niets anders dan voor elk ding een aparte operator definieren. Ik blijf er echter bij dat ik het nogal lomp vindt dat dit überhaupt mogelijk is. Het wordt al snel een unmaintainable zooitje op die manier.

[doeternietoe]

.oisyn schreef op donderdag 12 februari 2009 @ 22:31:
[...]

Dat ligt aan de context. Als je in de global namespace zit, dan 'A', want in de global namespace bestaat er alleen een 'bar' namespace.
Zit je in de namespace 'bar' zelf, dan is het 'B', want het enige dat 'bar' heet in de 'bar' namespace is die class. Mijn voorbeeld van daarnet was beter:

Uiteraard een foutje, de class "bar" had in de global namespace moeten zitten. Maar dan kom je op hetzelfde uit als jouw voorbeeld.

Je hebt dan in principe twee oplossingen: één van de twee opties laten voorgaan of het niet accepteren en een fatal error genereren. Met de laatste optie krijg je al problemen met oudere code waar in de global namespace een class met een naam bestaat en waar dan later mbv namespaces onderdelen aan toe worden gevoegd met een namespace die de naam van de klasse draagt. De mogelijkheid is wat hypothetisch, maar het laat wel zien wat een groot probleem van PHP is: alles moet backwards compatible zijn.

[drm]

Die backslash is echt een horrible keuze Dat even terzijde (over smaak valt niet te twisten)

Dat argument van de backwards compatibility is wel zulke ongelooflijke bullshit-flauwekul dat ik het toch tijd vind om daar eens een keer over te ranten . Ik weet 100% zeker dat ik 0 scoping bugs op hoef te gaan lossen in de twee jaar na dat php 5.3 stable is, in draaiende systemen die geupgrade gaan worden, om de simpele reden dat die scoping issues pas op kunnen treden als je namespaces gaat gebruiken. Je gaat wel "full retard" als je dan niet sowieso even in de bestaande code nagaat of de keuze van namespaces problemen oplevert. Hell, ik weet niet of ik uberhaupt namespaces zou gaan gebruiken als de rest van de code of libraries daar niet op gebaseerd zijn. Kies dan gewoon voor een fatal error of een order of preference, maar nee, we kiezen een andere operator. Obviously de weg van de minste weerstand.

Verder weet ik 100% zeker dat ik veel te veel tijd heb moeten besteden aan performance issues en reference-problemen in systemen die naar php5 zijn geupgrade. Backwards compatibility my ass. Ondertussen wordt geroepen dat de support voor zend.ze1_compatiblity_mode eruit wordt gesloopt (want dat heeft toch geen zin meer) terwijl elke flapdrol weet dat die compatibility mode aanzetten uitstel van executie is (en nog niet eens in alle gevallen de php4/php5 issues oplost), dus gewoon de issue oplost ipv die compatibility mode aan te zetten (die dus niet echt compatible is met php4).

En dan die undefined constants "feature". Wel aanraden om te programmeren met E_ALL error reporting, maar nog steeds die onzinnige backwards compatibility feature erin te houden omdat mensen sinds de release van PHP4 nog steeds niet weten hoe arrays in PHP werken is toch echt van de freaking pot gerukt, excuse me my french.

Kortom: flush die quasi compatibility bla-bla en maak nou gewoon eens keuzes met ballen. Zeg gewoon: In PHP5.3 (of PHP6 of PHP Vista of verzin een of andere flitsende versienaam, I don't care) cutten we de crap en moet je echt gaan programmeren in plaats van aan te prutsen".

* drm insert bij gebrek aan een smiley met stoom uit z'n oren deze:

[Cascade]

Om maar eens een oud topic op te rakelen; PHP 5.3 is nu officieel uit. Is iedereen al vol overtuiging bezig met namespaces?

Ik ben de laatste paar dagen bezig met kijken en testen hoe de nieuwe features werken. Word niet blij van de namespaces. Ik val niet zozeer over de estetisch verschrikkelijke notatie maar wel over de regels van de name resolution, en in het bijzonder dat je moeite moet gaan doen om terug te vallen op je global namespace bij het gebruik van classes.

Ik mag graag objecten doorgeven aan member functies met gebruik van type hinting. Als je nu met namespaces gaat werken kom je op die manier in de knoei met classes uit de global namespace, bijvoorbeeld PDO...

Een voorbeeld:

PHP:

namespace Foo;

class Bar
{
    public function fetchContent( PDO $pdo, $contentId )  { ... }
}

De PDO class wordt dan in namespace Foo verwacht, en dat gaat behoorlijk tegen mijn gevoel in. Natuurlijk kan je daar omheen door bijvoorbeeld de namespace in te stellen:

PHP:

public function fetchContent( \PDO $pdo, $contentId) { ... }

of door aliases te gebruiken:

PHP:

namespace Foo;
use \PDO;
use \PDOStatement;
use \PDOException;

Maar vind dat alles behalve logisch. Dat is toch verschrikkelijk zo? _{(om nog maar te zwijgen over akelig stille blanco output als PHP de class van een type hint niet kan vinden)} Zie ik iets over het hoofd hier?

Wat is jullie mening nu de namespaces in gebruik zijn?

[sky-]

Ik gebruik ze nog niet, ben nog niet echt overtuigd. En dan vooral, net zoals je zelf aanhaalt : "Ik mag graag objecten doorgeven aan member functies met gebruik van type hinting. Als je nu met namespaces gaat werken kom je op die manier in de knoei met classes uit de global namespace, bijvoorbeeld PDO..."

Dat probleem heb ik ook, en ik vind \ gewoon lelijk.

[Janoz]

Aliases komen op mij juist een stuk logischer over. Je gebruikt namespaces. Je zit in de ene namespace en je gebruikt een andere namespace, dan zul je toch aan moeten geven uit welke namespace dat komt? Ikzelf vind het erg overzichtelijk wanner bovenin staat wat gebruikt wordt. Daarnaast hoeft het ook nauwlijks extra werkt te zijn wanneer je goede ondersteuning hebt van je IDE.

Tenzij ik je punt mis. Ik gebruik weinig php meer en heb ook nog nooit met php's implementatie van namespaces gewerkt.

[ Voor 15% gewijzigd door Janoz op 07-07-2009 13:41 ]

[Niemand_Anders]

sky- schreef op dinsdag 07 juli 2009 @ 12:13:
Ik gebruik ze nog niet, ben nog niet echt overtuigd. En dan vooral, net zoals je zelf aanhaalt : "Ik mag graag objecten doorgeven aan member functies met gebruik van type hinting. Als je nu met namespaces gaat werken kom je op die manier in de knoei met classes uit de global namespace, bijvoorbeeld PDO..."

Dat probleem heb ik ook, en ik vind \ gewoon lelijk.

En dat is precies de reden dat .NET en Java geen global namespace kennen. Op het moment dat beide namespaces een class bevatten met dezelfde naam krijg je zelfs een compilatie error.

Via de using/import statements kun je dan een van de twee namespaces een alias geven en alle classes uit die namespace zijn dan alleen via die alias te benaderen.

Maar de namespace polution is niet vreemd voor PHP. Immers de enigste reden dat jij in classes this-> moet gebruiken is omdat PHP anders niet weet of je aan de class instantie of de global namespace refereert.

Maar vergeet niet dat deze 'pruts' methode wel een van de redenen is waarom PHP zo populair is. Je kunt het procedural gebruiken, maar ook in een OO context of zelfs gecombineerd. Dat PHP zoveel mogelijk backwards compatible wil blijven kan ik wel begrijpen. Voorbeelden uit een boek voor PHP3 (1998) zullen nu nog voor zo'n 90% werken. De grootste verandering is het wegvallen van de global variables die je nu via $_POST of $_GET moet benaderen.

[IntToStr]

Cascade schreef op dinsdag 07 juli 2009 @ 12:09:
Om maar eens een oud topic op te rakelen; PHP 5.3 is nu officieel uit. Is iedereen al vol overtuiging bezig met namespaces?

Ik ben de laatste paar dagen bezig met kijken en testen hoe de nieuwe features werken. Word niet blij van de namespaces. Ik val niet zozeer over de estetisch verschrikkelijke notatie maar wel over de regels van de name resolution, en in het bijzonder dat je moeite moet gaan doen om terug te vallen op je global namespace bij het gebruik van classes.

Ik mag graag objecten doorgeven aan member functies met gebruik van type hinting. Als je nu met namespaces gaat werken kom je op die manier in de knoei met classes uit de global namespace, bijvoorbeeld PDO...

Een voorbeeld:

PHP:

namespace Foo;

class Bar
{
    public function fetchContent( PDO $pdo, $contentId )  { ... }
}

De PDO class wordt dan in namespace Foo verwacht, en dat gaat behoorlijk tegen mijn gevoel in. Natuurlijk kan je daar omheen door bijvoorbeeld de namespace in te stellen:

PHP:

public function fetchContent( \PDO $pdo, $contentId) { ... }

of door aliases te gebruiken:

PHP:

namespace Foo;
use \PDO;
use \PDOStatement;
use \PDOException;

Maar vind dat alles behalve logisch. Dat is toch verschrikkelijk zo? _{(om nog maar te zwijgen over akelig stille blanco output als PHP de class van een type hint niet kan vinden)} Zie ik iets over het hoofd hier?

Wat is jullie mening nu de namespaces in gebruik zijn?

Nu heb ik nog niet gekeken naar alle rare fratsen met namespaces in PHP, maar zo op het eerste gezicht lijkt alles gewoon op Java te lijken:

• package declaration vs namespace declaration
• import statements vs use statements

Dat er nu \ ipv . wordt gebruikt ziet er misschien raar uit, maar doet er in principe niet toe natuurlijk. Als er een beetje grammatica bestaat zou het gewoon een . moeten kunnen zijn lijkt me. Klopt het nu dat het net leek alsof je meerdere namespace declarations in een bestand kunt hebben en dat die ook gebruikt kunnen worden als variabele? Dat lijkt me een rare keuze die tot veel problemen kan leiden, zoals de verplichte keuze voor \ ipv .

Zoals al eerder in deze thread aangegeven zijn die use statements uiteraard noodzakelijk per bestand, is ook logisch en prima. Je laatste voorbeeld met use \PDO en zo lijkt me ook gewoon wat je wilt hebben.

Binnenkort maar weer eens een uitstapje maken naar PHP om te spelen

[Woy]

Niemand_Anders schreef op dinsdag 07 juli 2009 @ 13:38:
[...]
En dat is precies de reden dat .NET en Java geen global namespace kennen. Op het moment dat beide namespaces een class bevatten met dezelfde naam krijg je zelfs een compilatie error.

offtopic:
.NET heeft wel een global namespace: http://msdn.microsoft.com/en-us/library/cc713620.aspx

[Cascade]

IntToStr schreef op dinsdag 07 juli 2009 @ 13:42:
[...]

Nu heb ik nog niet gekeken naar alle rare fratsen met namespaces in PHP, maar zo op het eerste gezicht lijkt alles gewoon op Java te lijken:

• package declaration vs namespace declaration
• import statements vs use statements

Mee eens, het lijkt direct overgenomen van de packages van Java. Grootste verschil is dat PHP met een erfenis zit van vele classes die eerst bijna als de primitieven van Java (correct me if I'm wrong), dus zonder namespace gebruikt werden en nu, als je ervoor kiest om te 'organiseren' in namespaces, in een grote global namespace gepropt worden die je dan ook verplicht moet gebruiken. Samen met de regels voor name resolution die soms niet terugvallen op die global namespace is dat niet zo prettig.

PDO is dan een specifiek voorbeeld; om dat te gebruiken moet je consequent die operator aangeven OF in na elke namespace die aliases aangeven. Dat zijn al 3 aliases, maar wat als je straks meer van die global namespace classes nodig hebt? Ik zie echt al waslijsten van aliases voor me:

PHP:

use \Exception; // het zal toch niet? durf het niet te testen...
use \PDO;
use \PDOStatement;
use \PDOException;
use \SimpleXMLElement;
// etc etc etc

Ik kom zelf van een C++ achtergrond, dan vind ik het vrij raar (of conservatief van mij ) dat hier de name resolution niet netjes door de hierarchie van (sub)namespaces loopt om dan uit te komen in de global namespace. De keuze voor het Java-model kan ik begrijpen, is ook prima, maar betekent wel een breuk met bestaande 'object-georienteerde' PHP en backward-compatibiliteit.

Zou liever zien dat ze PHP 6 nou in een keer goed doen, resoluut oude zooi de deur uit. Gaat vast niet gebeuren.