php - Getting base url, development variable, the best way, without using globals -

in application architecture want replace globals ain't gonna burn of developer's eyes, because using globals this,

define('development_environment', true);  // shorten directory_separator global, define('ds', directory_separator);  // set full path document root define('root', realpath(dirname(__file__)) . ds); 

how prevent this? tried creating class reads xml file, give me longer code this

$c = new config(); if($c->devmode === true) {} 

or maybe this

$c = new config() echo $c->baseurl; 

any better ways this?

i think questions yours can not answered deserve answer anyway. it's there not 1 golden rule or solution deal this.

at bare sense can imagine problem describe context application runs in. @ level of human face multi-folded, take one constant:

define('development_environment', true); 

even quite simple , introduced, comes high price. if part of application first try understand implications are.

you have 1 application codebase , somewhere in - in concrete everywhere constant used - there branches of code either executed if constant true or false.

this on it's own problematic because such code tends become complex , hard debug. regardless how (constant, variable, function, class) first of should reduce , prevent usage of such constructs.

and honestly, using (global) constant not wrong me, compared alternatives, first of preferable 1 in eyes because lies less , not complicated rather straight forward. turn less-dynamic constant in current php versions using const keyword declare however:

const development_environment = true; 

this 1 facet of little line of code. 1 low level of abstraction comes with. if want define environments application, saying development environment true or false ambiguous. instead have environment can of different types:

const environment_unspecified = 0; const environment_development = 1; const environment_staging     = 2; const environment_live        = 3;  const environment = environment_development; 

however little example example visualize mean make little ambiguous. not solve general problem outlined above and following one:

you introduce context application on level of global. means line of code inside component (function, class) relates global (here: development_environment) can not de-coupled global state longer. means you've written code works inside applications global context. stands in way if want write re-usable software components. re-usability must not mean second application, means in testing , debugging. or next revision of software. can imagine can stand in own way pretty fast - or let's faster want.

so problem here less constant on it's own more relying single context code run in or better worded global static state. goal need aim when introduce changes here better reduce global static state. important if you're looking alternatives because better decisions.

for example, instead of introducing set of constants have in last code-example, find places make use of development_environment , think why have put in there , if not possible remove out there. first think if needed @ (these environment flags smell, once needed in quick debugging or because thought "oh how practical" - , rotting in code on weeks of no use). after you've considered whether needed or not , came point needed, need find out why needed @ place. belong there? can't - should provides context - turned parameter?

normally objects definition ship own context. if you've got logger behaves differently in development in live, should configuration , not decision inside application code somewhere. if application has logger, inject it. application code logs.

so can imagine, totally depends on many different things how , when can prevent this. can suggest find out now, reduce overall usage.

there practical tips on way common scenarios face in applications. "root-path problem" can use relative paths in conjunction magic constants __dir__. example if front-endpoint in webroot (e.g. index.php) needs point private application directory hosting code:

<?php /**  * turbo cms - build race website's needs win.  *  * webroot endpoint  */ require(__dir__ . '/../private/myapp/bootstrap.php'); 

the application knows how works , find files relative itself. , if return application context object (and must not global(!)), can inject webroot folder well:

<?php /**  * turbo cms - build race website's needs win.  *  * webroot endpoint  */  /* @var $turboappcontext turbo\app\webappcontext */ $turboappcontext = require(__dir__ . '/../private/myapp/bootstrap.php'); $turboappcontext->setwebroot(__dir__); 

now context of webserver configures application defaults. crucial part because touches field of context inside application (but not in every component) immanent. can not prevent context. it's leaking abstractions. there environment (known "the system") application runs in. though, want make independent possible.

like development_environment constant above, these points crucial reduce , find right place them. allow specific layer set input values (to change context) , high-level layers of software access these values. largest part of code-base should work without of these parameters. , can control access passing around parameters , not using global. code on level allowed access setting (in best meaning of word), can access - else not have parameter. safety, need kill globals best possible.

e.g. functionalitly redirect location needs base-url of current request. should not fetch them server variables based on request-object abstracts access server variables can replace things here (e.g. when you're moving application behind front-proxy - not best example can happen). if have hard-coded software against $_server need modify $_server in stages of software. don't want that, instead move away (again) global static state (here via superglobal variable, spot next global constants) using objects represent functionality application needs.

as long we're talking web-applications, take @ symfony's request , response abstraction (which used many other projects makes application more open , fluent). side-note.

so whatever want base decision on, not misguided how many letters type. benefit of short-sighted when start consider overall letters need type when developing software.

instead understand introduce context, can prevent , can't. places can't, consider make context parameter instead of "property" of code. more fluent code allows more re-usable code, better tests , less hassles when move platform.

this important if have large installation base. code on these bases global static state mess maintain: late releases, crawling releases, disappointed developers, burdensome development. there lessons learn, , lessons understand implications features of language have , when use them.

the best rule can give - , i'm not academic developer @ - consider global expensive. can superb shortcut establish should know price comes with. , field wide because not apply object oriented programming procedural code well. in object oriented programming many educational material exists offers different ways prevent global static state, situation there quite documented. php not purely oop it's not easy having object @ hand - might first need introduce (but then, see request , response abstractions available).

so best suggestion can give improve code in context of question is: stick constant(s) (maybe const keyword make them less dynamic , more constant-ly) , try remove them. written in comments already, php fine job cross-platform file-access, use / directory separator, understood , works well. try not introduce root-path constant anyway - should not constant code write parameter on level - can change, example in sub-requests or sub-apps can save life-span before re-inventing wheel again.

the hard task keep things simple. it's worth.