[PHP] global of niet?

[TangLeFuzZ]

Hey,

wat is jullie mening over variabelen in een functie gebruiken met global in PHP? (vars die je dus buiten de functie declareert en binnen de functie gebruikt met global $var)

Ik zit een beetje met een soort van twijfel over m'n configuratie bestand.

Ik wil dat configuratie bestand graag mooi overzichtelijk houden. Op dit moment gebruik de config in een class, op deze manier;

PHP:

class Config 
{
    function Config( ) 
    {
        
        // mysql configuratie
        $this->tblArticles = "sdf";
        $this->tblArticlePages = "sdferwt";
        $this->tblArticleCats = "etyer";
    }
}

In een andere class haal ik dan eerst de variabelen binnen:

PHP:

class Articles 
{   
    function Articles( &$Config ) 
    {
        
        $this->config =& $Config;
        
        $this->tblArticles = $this->config->tblArticles;
        $this->tblArticlePages = $this->config->tblArticlePages;
        $this->tblArticleCats = $this->config->tblArticleCats;
    }
}

een andere manier die minder omslachtig is is in een configuratie bestand een array voor de config aan te maken;

$config['tblArticles'] = "sdfsd";
$config['tblArticleCats'] = "k45sd";

en die binnen functies te gebruiken met global $config

Ik ben altijd aangeleerd dat global $var vies is (ook vaak hier op GoT gelezen), maar waarom weet ik eigenlijk niet eens... kan iemand me hier misschien wat duidelijkheid over geven?
Waarom het eigenlijk 'vies' is, en of het ook in dit geval wel vies is?

[ Voor 22% gewijzigd door TangLeFuzZ op 08-01-2005 00:52 ]

[NMe]

Globals zijn vies omdat die je code minder doorzichtig maken, en ook minder portable. Een functie die alles door krijgt in parameters kun je zo gebruiken in een andere applicatie. Wanneer je afhankelijk bent van een global kan dat niet zomaar.

[Helmet]

ik zelf maak gebruik van een systeem met classes in classes
core.php

PHP:

class myModule 
{ 
 var $core; 
 // Constructor 
 function myModule(  &$core ) { $this->core = &$core;   } 
}

/* 
Core class, intercommunication between the various modules 
*/ 
class core  
{ 
 // Clasvars 
 var $oldVersion;
 var $startTime;
 var $bench;
 var $session;
 var $tp;
 var $db; 
 var $dummy; 
 var $modules = array(); 
 // Constructor 
 function core() 
 { 
   error_reporting(E_ALL); 
   $this->modules[] = 'modules/modbenchmark.class.php';
   $this->modules[] = 'modules/modsession.class.php'; 
   $this->modules[] = 'modules/modconfig.class.php'; 
   $this->modules[] = 'modules/moddb.class.php'; 
   $this->modules[] = 'smarty/libs/Smarty.class.php';

   foreach ($this->modules as $value) { require_once($value); } 
   
   $this->bench = &new benchmark($this);
   $this->startTime = $this->bench->getmicrotime();
   $this->config = &new config($this); 
   $this->session = &new session($this);
   $this->db = &new db($this); 
   $this->tp = &new smarty();
 } 

 function go($location)
 {
  $go = header("Location: " . $location);
 }
 // mods_loaded() 
 // returns an array with the modules currently loaded in the memory 
 function mods_loaded() { return $this->modules; } 
}

modbenchmark.class.php

PHP:

<?
 class benchmark extends myModule
 {
  var $start;
  var $end;
  
  # Constructor
  function benchmark(&$core)
  {
   parent::myModule(&$core);
  }

  function getmicrotime() 
  { 
   list($usec, $sec) = explode(" ", microtime()); 
   return ((float)$usec + (float)$sec); 
  } 
 }
?>

in mijn index.php maak ik gewoon de classe core aan, die automagisch alle andere classes initialiseerd, nu kan ik gebruik maken van $core->bench->getmicrotime() of $core->db->db_query($sql);

ook vanuit modules kan ik met elkaar communiceren door gebruik te maken van $this->core->db->db_query($sql); misschien is dit wat je zoekt.

[TangLeFuzZ]

-NMe- schreef op zaterdag 08 januari 2005 @ 00:51:
Globals zijn vies omdat die je code minder doorzichtig maken, en ook minder portable. Een functie die alles door krijgt in parameters kun je zo gebruiken in een andere applicatie. Wanneer je afhankelijk bent van een global kan dat niet zomaar.

Erg sterk punt inderdaad... met gebruik van global gaan de voordelen van een functie eigenlijk direct al verloren

Helmet; zal zo je post eens goed doornemen...ziet er interessant uit.

[Helmet]

nja als je even contact met me opneemt kan ik je wel een db module bijvoorbeeld sturen zodat je wat meer overzicht hebt over wat er allemaal mogelijk is

[djluc]

Ik werk binnen het Typo3 framework. Daar roep je de DBA aan met iets als:

PHP:

$GLOBALS['TYPO3_DB']->exec_SELECTquery();

Alle code binnen dit framework is echter specifiek op Typo3 gericht. Bijvoorbeeld: een module die je ontwikkeld wordt opgebouwd binnen een Typo3 class. De code is dus sowieso niet portable.

[eamelink]

TangLeFuzZ schreef op zaterdag 08 januari 2005 @ 00:55:
[...]
Erg sterk punt inderdaad... met gebruik van global gaan de voordelen van een functie eigenlijk direct al verloren

Mwoah, in essentie zijn functies niet meer dan een groepje code die je gemakkelijk kan aanroepen. In veel gevallen hoeven functies ook niet portable te zijn. Dan vind ik het gebruik van globals niet slecht opzich.

Als heb je ze natuurlijk bij normale codewerkzaamheden vrij weinig nodig, soms komt het gewoon zo uit dat het lekker makkelijk is.

En uiteindelijk draait het daar toch allemaal om

[PanMan]

eamelink schreef op zaterdag 08 januari 2005 @ 01:13:
_{Telefoonnummers moeten óók in de DNS'en komen!" - "Bel eamelink.nl!"}

offtopic:
Telefoonnummers staan toch in Whois?

[Creepy]

Ik heb het idee dat deze discussie al wat vaker is langsgekomen. Zie bijv. http://gathering.tweakers...D=&select_forum=#hitstart

Ook het gebruik van een zogenaamde singleton is de laatste tijd ook wat vaker als discussie punt gesignaleerd hier op GoT

Gebruik de search eens om de boel eens door te nemen, want voor zover ik het nu lees is het een behoorlijke herhaling. Zeker de posts van -NMe- en eamelink zijn al posts die ze allebei volgens mij al vaker hebben gemaakt

[bgever]

Om nog even op de TS in te springen: waarom gebruik je voor je configuratie geen constanten? Ik neem aan dat je de configuratie niet hoort te wijzigen, en constanten zijn over alle scripts geldig. Daarbij kun je deze mooi aanroepen:

PHP:

define( 'DB_HOST', 'localhost' );
define( 'DB_USER', 'pietje' );
define( 'DB_PASS', 'geheim' );

[...]

$connectie = mysql_connect( DB_HOST, DB_USER, DB_PASS );

Verder is global best te gebruiken, maar als je al veel hebt geprogrammeerd, dan merk je dat dit gewoon lastig werkt. Vooral als je wijzigingen maakt. Verder is het niet altijd duidelijk wanneer een variabele global is. Het werkt wel, maar het is gewoon niet prettig in het gebruik.

[Verwijderd]

Misschien zie ik iets over het hoofd, maar waarom zouden global variables wel "lastig" of "vies" zijn en constanten niet?

[flashin]

http://gerard.yoursite.nl/got/php-tiplist/#10
Overigens ben ik het met lang niet alles eens wat daar staat hoor

A constant is an identifier (name) for a simple value. As the name suggests, that value cannot change during the execution of the script (except for magic constants, which aren't actually constants). A constant is case-sensitive by default. By convention, constant identifiers are always uppercase.

[ Voor 89% gewijzigd door flashin op 08-01-2005 23:40 ]

[Verwijderd]

Het verschil tussen een constant een global variabele was mij wel duidelijk, dankjewel
Wat mij niet duidelijk is, is waarom constants niet "evil" zijn en globals wel. Bekijk het volgende:

PHP:

$link = mysql_connect(DB_HOST,  DB_USER, DB_PASS);

En nu het volgende:

PHP:

$link = mysql_connect($DB_HOST, $DB_USER, $DB_PASS);

Is het laatste nou echt zoveel viezer dan het eerste?

Eigenlijk zou je natuurlijk en geen constants en geen globals moeten gebruiken, tenminste niet in de scope van je hele script. Jammer genoeg ondersteunt PHP voorzover ik weet geen module-level globals (PHP ondersteunt op zich geen modules of packages, o.i.d. ).

[Creepy]

globale variabelen kunnen overal aangepast worden. Je weet op den duur niet meer waar welke globale variabele aangepast wordt. Hierdoor wordt het ook moeilijker om te controleren (of te bewijzen) dat je geschreven code ook daadwerkelijk correct werkt.

Een constante is vaak niet meer dan een naampje geven aan een nummer. Deze constanten veranderen nooit en hebben dus ook geen impact op het controleren of bewijzen dat je code correct werkt. Ze maken je code alleen veel beter leesbaar.

Dus ja, dat laatste, met die globale vars, is veel viezer. Met de constanten is het statement elke keer hetzelfde, met globale vars zou je (per ongeluk) iets aan kunnen passen wardoor de volgende keer dat je het statement uitvoert er niet gebeurt wat je verwacht omdat je bijv. per ongeluk in een functie oko een $DB_PASS variabele gebruikte.

[ Voor 3% gewijzigd door Creepy op 09-01-2005 12:59 ]

[Verwijderd]

Creepy schreef op zondag 09 januari 2005 @ 12:59:
Dus ja, dat laatste, met die globale vars, is veel viezer.

Dat vind ik een te absolute bewering voor deze vraag. Het hangt er imho nogal vanaf waar de variabelen en de connect call staan.

Als de variabelen vlak boven de connect call staan gedefiniëerd (voor de leesbaarheid, dus), dan maakt het niet zoveel uit natuurlijk. De global kan tussen definitie en gebruik toch niet van waarde veranderen, en naderhand is hij niet belangrijk meer. Misschien is daarvoor een global gebruiken zelfs nog makkelijker te lezen (t.o.v een constante definiëren). Vergelijk:

PHP:

$DB_USER = "pietje";

met

PHP:

define("DB_USER", "pietje");

De assignment is makkelijker te lezen en te begrijpen (ook voor niet-programmeurs, of programmeurs die een andere taal dan PHP gewend zijn).

Als het gebruiken van de global zich op een totaal andere plek in de code afspeelt is het misschien een ander verhaal, maar kom op: welke programmeur met een beetje hersens gaat nou aan een variabele genaamd $DB_PASS zitten morrelen? (Of vraagt zich überhaupt af wat er toch in zou zitten?) Je code komt uiteindelijk toch niet in een vijandige omgeving terecht[1]; je code komt terecht bij andere code die in combinatie met de jouwe iets nuttigs wil bereiken (namelijk het ophoesten van een webpagina). Je hoeft er dus niet van uit te gaan dat de andere code expres zal proberen jouw snippet onderuit te halen door globals te gaan vernietigen.

Van de andere kant, als de global gebruikt wordt in een functie is er een hele goeie (luie ) reden om constanten te verkiezen boven globals: je hoeft het global statement niet te gebruiken om bij de variabelen te komen.

Dus om te zeggen dat globals altijd vele malen viezer zijn dan constanten, nee, daar ben ik het niet mee eens. Globals zijn soms iets riskanter, vaak maakt het geen verschil, en in het beste geval zijn ze beter leesbaar.

Let wel, ik reageer hier op dit specifieke geval. Dit is geen betoog voor globals over constanten in elke instantie. Maar ik vind dat er best een beetje tegengas gegeven mag worden tegen de `globalfobie' die nogal schijnt te heersen in programmeerkringen.

En na deze beschouwing mijn eigen mening: ik gebruik een associatieve array.

PHP:

$dbinfo["user"]

Vind ik nog altijd het netste, en met constanten kun je dat niet.



_{[1] Ik bedoel met `omgeving' hier de rest van de websitecode. Natuurlijk is de grote boze buitenwereld wel vijandig, maar daar heb ik het niet over.}

[NMe]

Verwijderd schreef op zondag 09 januari 2005 @ 20:46:
Let wel, ik reageer hier op dit specifieke geval. Dit is geen betoog voor globals over constanten in elke instantie. Maar ik vind dat er best een beetje tegengas gegeven mag worden tegen de `globalfobie' die nogal schijnt te heersen in programmeerkringen.

Die globalfobie is er nou eenmaal niet voor niks. Bij een global variabele zie je bijvoorbeeld veel moeilijker of ie nou als "constante" bedoeld is, of dat het daadwerkelijk een variabele is die aangepast moet worden. Verder zul je veel eerder geneigd zijn om de variabele aan te passen. Het is gewoon een potentiële risicofactor die je moet minimaliseren, en zeker als je met meerdere mensen aan één project werkt. Misschien denkt een teamgenoot er wel heel anders over, en is hij wel heel strict in het gebruik van constanten. (Wat ik heel terecht vind. Wat nou, een define is moeilijker te begrijpen? ) Diegene gaat heel raar opkijken van je code, en moet zich er totaal doorheen gaan worstelen.

Een global gebruiken van tijd tot tijd kan zeker handig zijn, maar ik zou het vermijden waar mogelijk. Het is een potentiële bron van onduidelijkheid en verwarring, en die moet je niet hebben in je code.

[Verwijderd]

Bij een global variabele zie je bijvoorbeeld veel moeilijker of ie nou als "constante" bedoeld is, of dat het daadwerkelijk een variabele is die aangepast moet worden.

Onzin, gewoon de variabele in hoofdletters zetten en het is duidelijk. Hoofdletters gebruiken voor een constant is in heel veel talen de manier om aan te geven dat iets constant (of hoe die taal dat ook noemt) is. Dat er geen $ voor staat, zal niet zoveel uitmaken.

Verder zul je veel eerder geneigd zijn om de variabele aan te passen.

Waarom zou je dat dan doen?

Misschien ten overvloede: constants zijn idd over het algemeen wel te prefereren over globals, maar ze zijn zeker niet viezer. Er zijn natuurlijk wel zat voorbeelden te verzinnen van vieze globals, maar niet ter vervanging van constants.
Voorbeeldje van vieze globals:

PHP:

function d($a, $b)
{
    $GLOBALS['c'] = $GLOBALS['a'] + $GLOBALS['b'];
}
$a = 1;
$b = 1;
d();
echo $c;

Zulke code heb ik echt gezien! (maar dan met zinnige functionaliteit).

TS, je huidige config systeem is prima. Alleen zou ik het zo doen:

PHP:

class Articles 
{    
    function Articles($tblArticles, $tblArticlePages, $tblArticleCats) 
    {
        
        $this->tblArticles = $tblArticles;
        $this->tblArticlePages = $tblArticlePages;
        $this->tblArticleCats = $tblArticleCats;
    }
}

Zo is de manier waarop je je configuratie opslaat veel flexibeler.

[Verwijderd]

Wat misschien nog praktischer is, is het gebruik van klassevariabelen[1]:

PHP:

/**
 * Basisklasse
 *
 * Deze klasse is voor een willekeurige website te gebruiken; de tabeldetails
 * worden er buiten gehouden. Ideale plek voor deze klasse is in een library.
 */
class AArticles  
{     
  var $tblArticles = "";
  var $tblArticlePages = "";
  var $tblArticleCats = "";

  function checkAbstr() {
    if (!($this->tblArticles && $this->tblArticlePages && $this->tblArticleCats))
      trigger_error("Abstracte fout! Klasse AArticles moet overschreven en ingevuld worden!", E_USER_ERROR);
  }

  function doeIets() {
    $this->checkAbstr();
    
    // ... Nutige functionaliteit hier ...    
  }
}

/**
 * Concrete klasse
 * 
 * Deze maak je aan en instantiëer je in je project.
 */
class MySiteArticles extends AArticles {
  var $tblArticles = "foo";
  var $tblArticlePages = "bar";
  var $tblArticleCats = "baz";
}

$art =& new MySiteArticles();
$art->doeIets();

Op deze manier heb je herbruikbare logica die gescheiden is van de implementatiedetails (de tabelnamen). Als je bovendien nog iets wilt veranderen in de werking van de basisklasse voor je specifieke website, dan kun je dat op een nette manier doen -- zonder de library aan te passen -- door methodes van de basisklasse te gaan overschrijven.

In essentie gebruik je de programmeertaal zelf nu ook als configuratietaal.

_{[1] Of toch de imitatie daarvan in PHP}

[ Voor 15% gewijzigd door Verwijderd op 09-01-2005 22:14 ]

[NMe]

Verwijderd schreef op zondag 09 januari 2005 @ 21:18:
Onzin, gewoon de variabele in hoofdletters zetten en het is duidelijk. Hoofdletters gebruiken voor een constant is in heel veel talen de manier om aan te geven dat iets constant (of hoe die taal dat ook noemt) is. Dat er geen $ voor staat, zal niet zoveel uitmaken.

Ik zal het simpel zeggen: waarom constanten faken als je echte constanten hebt? Lekker moeilijk doen...

Waarom zou je dat dan doen?

Jij niet, maar iemand anders die je code moet aanpassen misschien wel...

Verwijderd schreef op zondag 09 januari 2005 @ 22:12:
Wat misschien nog praktischer is, is het gebruik van klassevariabelen:

Dat sowieso; maar dat zijn dan ook geen globals. Die variabelen zijn alleen binnen de scope van die klasse geldig, en dus, volgens mijn redenatie, volledig legaal.

[Verwijderd]

-NMe- schreef op zondag 09 januari 2005 @ 22:30:
[...]
Dat sowieso; maar dat zijn dan ook geen globals. Die variabelen zijn alleen binnen de scope van die klasse geldig, en dus, volgens mijn redenatie, volledig legaal.

Hehe .

Die post van mij was eigenlijk meer in reactie op de TS dan op de globals discussie.

[creative8500]

Ik heb niets van het topic gelezen, maar ik wil graag kernachtig reageren op de vraag die in de eerste zin van de topicstart gesteld werd: wanneer je een project "echt eens een keer 'goed' wilt doen", gebruik dan geen globals. Het nodigt, zeker in PHP, enorm uit tot hacks: "verdikkie, hoe krijg ik die informatie nu deze functie binnengesmokkeld? Dan maar een global, tot ik bedenk hoe het definitief vorm moet krijgen." Je beland door zo'n instelling in een vicieuze cirkel, en het is lastig om daaruit te komen.

_{Maak liever gebruik van bijvoorbeeld een Context-object, waar je netjes de relevante informatie bijhoudt. Gebruik het niet als een array om functieparameters door te geven, maar echt als 'context' binnen je applicatie. De configuratie is dan onderdeel van de context waarin een methode wordt uitgevoerd.}

[ Voor 10% gewijzigd door creative8500 op 09-01-2005 22:51 ]

[TangLeFuzZ]

Verwijderd schreef op zondag 09 januari 2005 @ 20:46:
Als het gebruiken van de global zich op een totaal andere plek in de code afspeelt is het misschien een ander verhaal, maar kom op: welke programmeur met een beetje hersens gaat nou aan een variabele genaamd $DB_PASS zitten morrelen? (Of vraagt zich überhaupt af wat er toch in zou zitten?)

Dat denk ik dus ook... als je je globale variabelen een goeie prefix mee geeft zal het niet voorkomen dat je hem per ongeluk wijzigd.

Verwijderd schreef op zondag 09 januari 2005 @ 20:46:
Van de andere kant, als de global gebruikt wordt in een functie is er een hele goeie (luie ) reden om constanten te verkiezen boven globals: je hoeft het global statement niet te gebruiken om bij de variabelen te komen.

Hier is misschien het volgende tegenargument voor te gebruiken; als je ergens global ziet staan in een functie zie je direct dat die variabele ergens anders vandaan komt... als je een functie snel doorleest, zie je waarschijnlijk op het eerste oog niet dat er een constante in wordt gebruikt.
Kan makkelijk zijn met het hergebruiken van functies...

Verwijderd schreef op zondag 09 januari 2005 @ 21:18:

TS, je huidige config systeem is prima. Alleen zou ik het zo doen:

PHP:

class Articles 
{    
    function Articles($tblArticles, $tblArticlePages, $tblArticleCats) 
    {
        
        $this->tblArticles = $tblArticles;
        $this->tblArticlePages = $tblArticlePages;
        $this->tblArticleCats = $tblArticleCats;
    }
}

Zo is de manier waarop je je configuratie opslaat veel flexibeler.

Ik haal in elke klasse erg veel informatie uit m'n config class, die constructor zou dan gigantisch veel variabelen meegegeven moeten krijgen, lijkt me niet echt fijn werken.

Ik denk toch dat ik constanten ga gebruiken.... met de juiste prefix lijkt me dit in mijn geval toch de juiste keuze.
M'n code hoeft op zich niet 100% portable te zijn, het is erg specifieke code voor m'n website en ik denk niet dat ik het snel ergens anders zou gebruiken.
Ik plaats gewoon goed en uitgebreid commentaar boven elke functie, stel dat ik hem wil hergebruiken, dan staat er in het commentaar waar alles vandaan komt.

Ik ga er alleen nog wel goed over nadenken, want de manier waarop ik het eerst deed (met die hoofd configuratie class), is wel het veiligst volgens mij...

Want is het niet zo, dat iemand die een exploit in je site vind, zo een globale variabele of constante zou kunnen weergeven?
In het geval van mijn allereerste voorbeeld (in startpost), kan dit niet, toch?

Verwijderd schreef op zondag 09 januari 2005 @ 22:12:
Wat misschien nog praktischer is, is het gebruik van klassevariabelen[1]:

Dit ziet er ook wel handig uit... ik neem aan dat je die Concrete klasses, allemaal in 1 'configuratie' bestand aanmaakt, of niet?
(anders heb je als nog je configuratie over meerdere files verspreid, en dat is niet de bedoeling)

[ Voor 17% gewijzigd door TangLeFuzZ op 10-01-2005 08:44 ]

[Creepy]

Verwijderd schreef op zondag 09 januari 2005 @ 21:18:
[...]

Onzin, gewoon de variabele in hoofdletters zetten en het is duidelijk. Hoofdletters gebruiken voor een constant is in heel veel talen de manier om aan te geven dat iets constant (of hoe die taal dat ook noemt) is. Dat er geen $ voor staat, zal niet zoveel uitmaken.

Als je een globale var als constante gebruikt, waarom er dan ook geen echte constante van maken om er zo 100% zeker van te zijn dat het ook echt als constante wordt gebruikt?

Waarom zou je dat dan doen?

Omdat het kan. Omdat volgend jaar iemand anders de code gaat onderhouden en het niet als constante gebruikt. Omdat je per ongeluk een variabele met dezelfde naam ergens anders ook al gebruikt. En er zijn nog wel meer varianten te verzinnen denk ik