[oop] gebruik defines
Een kort vraagje. Mogen onderdelen van een framework vertrouwen op defines? Stel je hebt een kernel class en die heeft het root path nodig. Vevolgens zijn er nog een paar andere classes die ook het root path gebruiken. Nu kan ik aan de constructor van de kernel class het root path meegeven. Vervolgens geeft de kernel class het root path weer door aan andere classes. Dat is optie 1. Ik vraag me nu af of het oké is om alvorens de kernel class aan te roepen het root path te definen en dan in de kernel class en op overige plekken waar het nodig is gebruik te maken van de defined constant. Dus in plaats van telkens via de constructor het root path door te geven, define je het root path eenmalig en gebruik je overal die constant. Is dat oké?
Gewijzigd op 11/06/2014 10:29:36 door Ozzie PHP
Je moet per slot van rekening ergens beginnen, anders wordt configureren een onoplosbaar kip-en-eiprobleem. Om bijvoorbeeld iets te kunnen laden met een autoloader, moet je eerst de autoloader zelf laden en dus expliciet declareren wáár die te vinden is.
Definieer je niet expliciet constanten, dan is er altijd nog een standaardconfiguratie waarop veel standaardklassen impliciet blindvaren of terugvallen: php.ini. Daar heb je dus nog wel een keuze. Bijvoorbeeld verbindingsparameters voor de databaseserver kun je in constanten of in php.ini vastleggen.
Maar het is dus niet "fout"?
Eerst deed ik dus bijv. dit:
En nu zou ik dan gewoon dit doen?
Het is dus niet "verkeerd" dat die kernel vertrouwt op een defined constant die buiten de class wordt aangemaakt?
Gewijzigd op 11/06/2014 11:07:57 door Ozzie PHP
Je kunt zo'n declaratie beter wel expliciet maken, dus die ergens in het script uitschrijven. Of je plaatst de volledige configuratie centraal in één gemeenschappelijk config.ini of in een gedeelde interface, als het maar logisch, duidelijk en consistent is. Je wilt geen class Kernel in Kernel.php hebben die achter de schermen en daarmee onzichtbaar iets uit een kernel.ini gebruikt.
Ik dacht dat dat als container zou gaan dienen, voor wat je nu weer anders benadert.
Toevoeging op 11/06/2014 11:22:01:
kan het topic niet terug vinden
Code (php)
1
2
3
2
3
<?php
$config->get('root_path', ROOT_PATH);
?>
$config->get('root_path', ROOT_PATH);
?>
Eerste param is de key van de config array, bestaat hij niet dan geeft hij de 2de param terug.
Gewijzigd op 11/06/2014 11:25:03 door Joakim Broden
Goed punt. Maar inderdaad. Zo'n configuratie zou ik in een apart bestand zetten. Maar een root path heb je op diverse plekken nodig, daarom is een define in dit geval wel mooi denk ik.
>> Ozzie was toch laatste bezig met een class waarin allerlei constanten gedefinieerd werden?
Ik gebruik wel een container, en daar komen ook paden in. Maar om die te maken, moet ik wel eerst een root path hebben :)
Zo'n root path heb je op een paar plekken nodig. Mijn 1e gedachte was dus om een variabele te gebruiken en die door te geven aan de constructor van de kernel, en de kernel geeft 'm dan weer door aan de class die de absolute paden aanmaakt. Maar wat er dus gebeurt is dat ik telkens dat root path via de constructors loop door te geven. Een define is dan denk ik handiger.
Vanaf PHP 5.6 kun je functies en contanten importeren: https://wiki.php.net/rfc/use_function
Thanks!
Dat is precies de rede waarom je superglobals niet in functies moet gebruiken, waarom het "global" keyword uit den boze is en waarom "passed by reference" zo verkeerd is. Aan dat rijtje mag je nu ook toevoegen: Het gebruik van globale constanten in een functie.
1) Er zijn hier uitzonderingen voor, de zogenaamde IO functies, maar die kom je maar zelden tegen. Dat is bijv. de echo functie (als dat een functie zou zijn) en een fwrite functie.
Code (php)
en niet dit:
Ben jij het daar mee eens? Bij mij gaat het enkel dan om een ROOT_PATH constant die ik op een paar plaatsen nodig heb om bijv. configuratiebestanden in te lezen.
Nog voor de compilatie (in talen als C) en uitvoering van het programma worden de constanten vervangen door de tekst/waarde waar de constante voor staat.
Code (php)
Toevoeging op 11/06/2014 22:21:36:
Ik vind een root path meer een configuratie variabele die door een gebruiker (lees systeembeheerder) nog aangepast mag worden. Indien jij van mening bent dat dat in jou geval er NOOIT een reden zal zijn waarbij de root path zal hoeven te wijzigen (door iemand anders dan de programmeur zelf) dan kun je deze prima met een define aanmaken.
Wat ik bedoel te zeggen is dat een define iets in de programmacode is en dus nooit meer gewijzigd kunnen worden door mensen die niet bij de source kunnen.
Nee, een root path is een root path toch :) Daar hoeft inderdaad niemand anders dan de programmeur bij te komen. Dus in dat geval geen probleem begrijp ik?
Zie hier het framework zelf en het project waarin je het gebruikt als 2 andere dingen. Wanneer het binnen het framework *altijd* (dus in ieder project) hetzelfde is, dan nog zou ik het niet doen, maar dan zou Frank zeggen: doen. Wanneer dit niet het geval is en je het per project moet veranderen dan zijn Frank en ik het met elkaar eens: Niet doen
Wouter, waarom zou jij het niet doen? Het alternatief is het doorgeven via de constructor. Dat is toch ook een beetje overkill? Het is een vaste waarde die verder niet hoeft te worden aangepast. Ik ben het volledig met je eens dat je het in 99% van de gevallen niet moet doen, maar hier zou het toch kunnen lijkt me.
>> Ik kan me situaties indenken waarin je een root-path toch wilt wijzigen. Denk maar eens aan de overstap van een windows-server naar een linux-server.
Je kan een root path van je framework dynamisch genereren, bijv: define('ROOT_PATH', __DIR__)
Of define('ROOT_PATH', '/path/to/framework')
Waarom zou je een root path willen wijzigen... snap niet helemaal wat je bedoelt :(
Goed, hij was eerst:
Nu verplaats je naar een linux server en tada:
>> Het is een vaste waarde die verder niet hoeft te worden aangepast.
Oh nee? Ik zal altijd aanraden om in productie de ROOT buiten de web root te laten vallen. Tadaa: dat is al wat anders dan in een development omgeving.
Ja, dan pas je 'm toch eenmalig aan in je index.php? Het gaat erom dat je 'm eenmalig defined (hoe je dat doet boeit toch niet?)
>> Oh nee? Ik zal altijd aanraden om in productie de ROOT buiten de web root te laten vallen. Tadaa: dat is al wat anders dan in een development omgeving.
Wat bedoel je nu? Kun je dit toelichten? Ik snap echt even niet wat je bedoelt. Onder de root map, versta ik de map waarin de public en de private directory staan.