?>
Klopt het dat in situatie 1 zowel class A als class B een eigen afzonderlijke "kopie" (property) opslaan van $array?
En klopt het dat er in situatie 2 slechts 1 versie van $array is (het object), en dat de class-properties in class A en B slechts pointers zijn naar $array (het object)?
@Ward: ik hoop dat je nog even een reactie geeft, want ik snap niet wat je bedoelde.
Ik heb wat moeite met twee dingen. Het eerste is het overladen van bestaande variabelen in nieuwe variabelen. Dit voegt niets toe, ongeacht of je een call by name of een call by reference gebruikt:
<?php
// In plaats van dit:
$foo = new Foo($x, $y);
// Doe je dit:
$z = array($x, $y);
$foo = new Foo($z);
?>
Ten tweede gebruik je niet zomaar een array, maar een array met de superglobal arrays zoals $_GET, $_POST en $_COOKIE. Vanwege hun speciale status in een PHP-omgeving horen die, volgens mij, niet allemaal in dezelfde controller te worden gestopt. Dat duidt op een onevenwichtige taakverdeling.
Bovendien hoef je ze niet eens door te geven als object of als array: ze zijn superglobal. In plaats van $form = new Form($_POST) kun je gewoon $form = new Form() gebruiken.
>> Vanwege hun speciale status in een PHP-omgeving horen die, volgens mij, niet allemaal in dezelfde controller te worden gestopt. Dat duidt op een onevenwichtige taakverdeling.
Ze komen ook niet in een controller, maar in een request object.
>> Bovendien hoef je ze niet eens door te geven als object of als array: ze zijn superglobal. In plaats van $form = new Form($_POST) kun je gewoon $form = new Form() gebruiken.
Oeh, dit bedoel je toch hopelijk niet serieus? Ga jij superglobals in je objecten gebruiken? Dan zijn je objecten toch 100% afhankelijk van die superglobals? Je moet ze juist meegeven, dan kun je de klasse gebruiken in welke omgeving het ook is. Ook als er geen POST request is, maar bijv. een GET request. En ook als ik aan het testen ben en er helemaal geen sprake is van superglobals.
Toevoeging op 31/10/2013 07:55:50:
En ozzie, waarom argumenten en geen array? Nou, waarom doe je niet:
<?php
new User(array('name' => 'Nienke', 'age' => '25', ...));
?>
Het zijn eigenschappen van het request object die je instelt. Ook kun je met een array geen default options instellen, etc.
@Ward: lees de reactie van Wouter. Het is niet correct om je superglobals zomaar "out of the blue" ergens vandaan te halen op het moment dat je ze nodig hebt. Dat is de oude (verkeerde) stijl van programmeren. Je objecten moeten zo "onafhankelijk" mogelijk zijn. Je moet er van buitenaf informatie instoppen, en je moet niet deze informatie van binnenuit ophalen, wat jij dus nu doet door superglobals te gebruiken. En daarnaast is het nog mooier om de informatie uit die superglobals in een request object te verwerken. Dus jouw eerdere reactie waarin je mij als controlfreak bestempelt lijkt me niet helemaal gepast.
@Wouter: ik begrijp je nog steeds niet helemaal.
a) In jouw voorbeeld met de user gebruik je zelf toch ook een array?
b) ik heb in dit geval geen defaults nodig omdat het om de superglobals gaat. Als die niet gevuld zijn (omdat er niks is gepost) dan wordt het automatisch een lege array.
En waarom ik alles in 1 array stop is omdat ik die informatie moet doorgeven aan een paar verschillende classes. Waarom zou ik dan telkens 5 variabelen (cookie, files, get, post, server) gaan doorgeven en ook telkens 5 class properties gaan setten, terwijl ik alles gewoon in 1 array $globals kan stoppen?
Ik begrijp dat je me iets duidelijk wil maken, alleen ik snap niet wat je nu precies bedoelt. Ik hoop dat je het nog even kunt toelichten.
In ieder geval zal minimaal één functie of object dan de superglobals moeten in laden.
Als ik de reactie van Wouter lees dan is dit de taak van de request object? Hoe ziet een simpele request object er uit dan? en ga je die daarna injecteren in de classes die hem nodig hebben?
Het tweede argument van Wouter daar kunnen we het allemaal wel mee eens zijn lijkt me. Hoe flexibeler je code is hoe beter.
>> Als ik de reactie van Wouter lees dan is dit de taak van de request object? Hoe ziet een simpele request object er uit dan? en ga je die daarna injecteren in de classes die hem nodig hebben?
De data uit de superglobals geef je via de constructor aan het request object mee. Het request object stop je in je service container. En inderdaad, het request object injecteer je in je classes/services die het nodig hebben.
>> Het tweede argument van Wouter daar kunnen we het allemaal wel mee eens zijn lijkt me. Hoe flexibeler je code is hoe beter.
Alleen begrijp ik dus niet wat Wouter bedoelt. Hij zegt dat je geen array moet gebruiken, maar doet dat zelf in zijn voorbeeld wel. En zie ook mijn opmerking hierboven waarom ik alles in 1 array stop. Dat lijkt me toch juist handig in dit specifieke geval? Ik ben dus benieuwd waarom dat (volgens Wouter) niet zo is.
> a) In jouw voorbeeld met de user gebruik je zelf toch ook een array?
Dus jij ziet dat als een best practise? Werk je dus nooit met meerdere argumenten, maar gebruik je slechts een array?
Ik hoopte dat ik duidelijk genoeg was dat het voorbeeldje van de User een manier is die je niet moet toepassen.
> En waarom ik alles in 1 array stop is omdat ik die informatie moet doorgeven aan een paar verschillende classes. Waarom zou ik dan telkens 5 variabelen (cookie, files, get, post, server) gaan doorgeven en ook telkens 5 class properties gaan setten, terwijl ik alles gewoon in 1 array $globals kan stoppen?
Als het goed is heeft alleen het Request object te maken met die globals.
>> Dus jij ziet dat als een best practise? Werk je dus nooit met meerdere argumenten, maar gebruik je slechts een array?
Nee, zeker niet. Maar dat wil niet zeggen dat het in sommige gevallen niet kan.
>> Als het goed is heeft alleen het Request object te maken met die globals.
Uiteindelijk wel, maar ik geef ze door via de kernel. Jij maakt eerst een request object en die stop je in je kernel. Ik stop de request data in de kernel en de kernel maakt een request object. Iets andere benadering dus.
En waarom doe je die methode van jouw dan? Wat is daar het voordeel van?
En daarnaast, als je zograag in de kernel een request object aanmaakt zou ik het gewoon in 1 keer met super globals in de kernel stoppen. De kernel is toch afhankelijk van het request geworden
>> En waarom doe je die methode van jouw dan? Wat is daar het voordeel van?
Ik vind het persoonlijk mooier en handiger, omdat de kernel/processor nu alles regelt. Ik stop de globale data in de kernel en die regelt vervolgens de rest. Eigenlijk doen we bijna hetzelfde. Jij geeft een object mee aan de kernel, maar ik geef de ruwe data mee. Dus op zich is er niet heel veel verschil. Jouw methode vind ik ook zeker niet verkeerd.
>> En daarnaast, als je zograag in de kernel een request object aanmaakt zou ik het gewoon in 1 keer met super globals in de kernel stoppen. De kernel is toch afhankelijk van het request geworden
Euh ja, maar dit is dan weer "jouw" methode? Of begrijp ik je nu verkeerd?
