[php] globale class defineren?

[RSpliet]

De topictitel mag dan wel niet al te helder zijn, waar ik naar zoek is een nette oplossing om in een klasse een andere klasse aan te roepen (om een variabele te wijzigen), die ik vervolgens ook buiten die klasse kan uitlezen door die klasse aan te roepen... Voorbeeld

PHP:

<?php
class error_handling {
    private $errno;

    function set($errno) {
        //doe verschillende checks
        $this->errno = $errno;
    }

    function get() {
        return $this->errno;
    }
}

class foe {
    function foe() {
        if(iets_faalde()) {
            error_handling::set(12);
        }
    }
}

$error = new error_handling;
$foe = new foe;
echo $error->get
?>

Wat de bedoeling is is dat die echo onderaan uiteindelijk dus 12 weergeeft. Echter doet die dat niet, omdat $error los staat van de error_handling::set(12); in $foe. Ik wil dit gebeuren dus niet met globals regelen, alleen via de error_handling klasse moet je de boel kunnen beheren, wijzigen etc. Globals zijn daarnaast gewoon vies naar mijn mening .
Door die class foe een extension van error_handling te maken (class foe extends...) kan ik wel wat werkends produceren, echter omdat die error handling 'globaal' moet zijn (die word ook in andere classes gebruikt) krijg ik 4 verschillende gelijke systemen, en zie ik door de bonsaiboompjes het bos straks niet meer. Dan krijg ik namelijk $foe->get en $bar->get, die hetzelfde doen, maar andere waarden teruggeven, en da's niet helder genoeg.
Vervolgens heb ik gedacht aan simpelweg in de class te zeggen "global $error", maar dan vrees ik dat dit voor elke functie apart moet, dat wordt een zootje.
Ga ik dit error-systeem met een zwikkie functies bouwen ipv een class, dan moet ik alsnog gebruik maken van $GLOBALS, en ook dat is dus niet zo netjes.
Hoe kan ik dit dus op een nette manier oplossen?

[elevator]

Moet je $errorno niet als static declareren?

[RSpliet]

hmm, niet alleen errorno blijkbaar, ook de get functie. Maar het werkt wel tnx

[ Voor 7% gewijzigd door RSpliet op 01-01-2005 19:48 ]

[Mithrandir]

Seven of Nine schreef op zaterdag 01 januari 2005 @ 19:47:
hmm, niet alleen errorno blijkbaar, ook de get functie. Maar het werkt wel tnx

Static betekent dat je die functie ook zonder object kunt aanspreken. Met andere woorden, als je geen object wilt maken maar wel functies aanspreken moet je ze altijd static declaren.

Eigenlijk is dat iets dat niet helemaal in een weak-typed programmeertaal hort imho, maar daar zullen een aantal mensen vast anders over denken.

[Michali]

Zo te zien heb je een statefull object die je op meerdere plaatsen wilt gebruiken. Een object zonder state (dus zonder velden) mag je eventueel puur static maken, maar in dit geval is het toch beter om het niet static te doen. Als je foe echt alleen binnen error_handling gebruikt kun je hem het beste gewoon als parameter aan de constructor doorgeven. Ga je hem al op meerdere plaatsen gebruiken, dan is het slimmer om er een singleton van te maken (precies wat je nodig hebt volgens mij):

PHP:

class error_handling
{
  private static $instance;

  public static function &getInstance()
  {
    if ( self::$instance == null )
    {
      self::$instance = new error_handling();
    }

    return self::$instance;
  }

  private function __construct() { }

  // de rest
}

error_handling::getInstance()->set(12);

Vrij simpel concept. De constructor is private zodat ie alleen vanuit binnen de class zelf aangeroepen kan worden. Twee instanties maken is dus ondenkbaar Je haalt het object dus statisch op om er vervolgens acties op uit te voeren.

Misbruik deze design pattern echter niet. Gebruik hem echt alleen wanneer je een statefull object op verschillende plaatsen moet kunnen bewerken, waarbij dan op de andere plaatsen deze waardes weer uitgelezen en/of bewerkt kunnen worden. Denk ik andere gevallen gewoon aan doorgeven via een parameter op aan aggregatie (en zeker geen inheritence voor dit soort zaken )

[RSpliet]

Michali schreef op zondag 02 januari 2005 @ 13:09:
Een heel mooi verhaal

Hmm, ziet er heel netjes uit allemaal. Echter werkt 'de andere manier' ook, en die is voor mij iets begrijpelijker.

PHP:

<?php
class error {
    static private $errno;
    
    function set($error) {
        self::$errno = $error;
        return true;
    }
    
    static function get() {
        return self::$errno;
    }
}
?>

Da's een simpele weergave van wat ik nu gebruik. error::set kan ik nu in een andere klasse aanroepen, en error::get overal. Als ik error::set aanroep buiten een klasse, dan 'werkt' het volgens mij wel, maar komt er een mooie strict warning. Echter zal dit nooit nodig zijn, de code is namelijk wel praktisch allemaal van mijzelf (ik hoef dus nergens rekening mee te houden). Stel dat iemand anders een nieuwe instance aanmaakt in zijn of haar code (en dit toevoegt aan mijn code dus), dan is dat hoogstens heel stom, dan issie namelijk afgezonderd van het 'echte' systeem

[Michali]

Het mooie van een singleton is dat je kunt afdwingen dat er maar 1 instantie gemaakt kan worden. Verder wordt die instantie ook pas gemaakt als getInstance() voor het eerst wordt aangeroepen, verder niet.

Bovendien heeft het ook nog als voordeel dat het een beweze design pattern in meerdere talen is. Het is gemakkelijk te porten (dat stukje van jou ook wel), en je kunt in 1 woord uitleggen wat je design intentie van de class is. Zoek maar eens op Singleton op google.

Verder zou ik set() ook statisch maken dan. Zo is het nog niet echt netjes.

[ Voor 4% gewijzigd door Michali op 02-01-2005 15:05 ]

[MisterData]

Los van dat je een class gaat maken om errors mee af te handelen, wat opzich goed is, maar waarom zou je geen gebruik maken van exceptions? Dan moet je natuurlijk wel PHP5 (kunnen) gebruiken, anders gaat dat natuurlijk niet op

[RSpliet]

MisterData schreef op zondag 02 januari 2005 @ 16:09:
Los van dat je een class gaat maken om errors mee af te handelen, wat opzich goed is, maar waarom zou je geen gebruik maken van exceptions? Dan moet je natuurlijk wel PHP5 (kunnen) gebruiken, anders gaat dat natuurlijk niet op

Zonder PHP5 kan ik ook niet bepalen of mijn functies/variabelen private of public zijn, en nog veel meer zaken niet. Ik doe dus mijn development in PHP5. In exceptions heb ik mij eerlijk gezegd nog niet zo verdiept, dat zal ik dus nog even doen. Exceptions lijken mij eerlijk gezegd niet direct nodig. De fouten die ik verwacht zijn in de trant van "gebruiker heeft de rechten niet een bericht te plaatsen (of een andere bewerking uit te voeren)", "query gaf geen data terug" en "Database vertelde mij dat dit en dat te lang was", en daar zal fout'ondervanging' toch niet zo veel bij helpen. Het zijn namelijk geen fouten in de code, maar fouten in de rechten die ik door middel van PHP inperk. Rechtoverschrijding ziet PHP niet vanzelf aan als fout, dus vandaar.

[ Voor 31% gewijzigd door RSpliet op 02-01-2005 22:26 ]

[Grijze Vos]

Mithrandir schreef op zaterdag 01 januari 2005 @ 21:28:
[...]


Static betekent dat je die functie ook zonder object kunt aanspreken. Met andere woorden, als je geen object wilt maken maar wel functies aanspreken moet je ze altijd static declaren.

Dat is niet bepaald wat static betekent. Static betekent dat alle instanties (ook 0 instanties) van een object dezelfde static content hebben. Nog niet een heel nette duidelijke formulering, maar toch zeker een deel van het static gebeuren wat je niet moet vergeten.

Eigenlijk is dat iets dat niet helemaal in een weak-typed programmeertaal hort imho, maar daar zullen een aantal mensen vast anders over denken.

PHP is niet weak-typed, maar dynamically typed.

[Michali]

Seven of Nine schreef op zondag 02 januari 2005 @ 22:17:
[...]


Zonder PHP5 kan ik ook niet bepalen of mijn functies/variabelen private of public zijn, en nog veel meer zaken niet. Ik doe dus mijn development in PHP5. In exceptions heb ik mij eerlijk gezegd nog niet zo verdiept, dat zal ik dus nog even doen. Exceptions lijken mij eerlijk gezegd niet direct nodig. De fouten die ik verwacht zijn in de trant van "gebruiker heeft de rechten niet een bericht te plaatsen (of een andere bewerking uit te voeren)", "query gaf geen data terug" en "Database vertelde mij dat dit en dat te lang was", en daar zal fout'ondervanging' toch niet zo veel bij helpen. Het zijn namelijk geen fouten in de code, maar fouten in de rechten die ik door middel van PHP inperk. Rechtoverschrijding ziet PHP niet vanzelf aan als fout, dus vandaar.

Alleen al dat je aangeeft dat je verschillende berichten wilt terug kunnen sturen bij een het stoppen van de normale flow geeft al aan dat exceptions hier toch zeker een veel betere uitkomst bieden. Je hoeft ten eerste niet moelijk te gaan zitten klooien met zo'n class en later gaan checken of er iets fout is gegaan. Je kunt veel beter een exception throwen met daarin het betreffende bericht, die je daarna probeert af te vangen. Ten tweede is je intentie ook nog een duidelijker en wordt je code er een stukje mooier van imo. Probeert het eens uit zou ik zeggen

En ik zie dat je probeert te werken met een message en een code. Check de exceptions manual eens dan zie je wat ik bedoel.

[ Voor 10% gewijzigd door Michali op 02-01-2005 23:34 ]

[RSpliet]

Michali schreef op zondag 02 januari 2005 @ 23:32:
[...]

Alleen al dat je aangeeft dat je verschillende berichten wilt terug kunnen sturen bij een het stoppen van de normale flow geeft al aan dat exceptions hier toch zeker een veel betere uitkomst bieden. Je hoeft ten eerste niet moelijk te gaan zitten klooien met zo'n class en later gaan checken of er iets fout is gegaan. Je kunt veel beter een exception throwen met daarin het betreffende bericht, die je daarna probeert af te vangen. Ten tweede is je intentie ook nog een duidelijker en wordt je code er een stukje mooier van imo. Probeert het eens uit zou ik zeggen

En ik zie dat je probeert te werken met een message en een code. Check de exceptions manual eens dan zie je wat ik bedoel.

Hoo wacht... zie ik daar 'trigger_error', die had ik even gemist. Dan is de boel dus in feite net zo makkelijk met exceptions, met het voordeel dat ik ook onverwachte fouten opvang (toch?)... Ik ga eens kijken of dat het effect is dat ik wil bereiken.

[Michali]

Ik denk eerlijk gezegd dat het nog een stuk gemakkelijker te maken is met exceptions. Je kunt namelijk ook zelf de basis exception class overerven en aanpassen. Binnen het catch statement kun je zo je eigen exceptions afvangen en er mee doen wat je wilt. Werkt wel erg lekker iig.

[Verwijderd]

Grijze Vos schreef op zondag 02 januari 2005 @ 23:03:
PHP is niet weak-typed, maar dynamically typed.

Het is het allebei .

PHP is weakly dynamically typed.

En ik kom hier net een heel verhelderend essay tegen over types.

[Sybr_E-N]

@Seven of Nine: Mag ik je wijzen op dit artikel. Hier worden de functionaliteiten van Exceptions in PHP5 beschreven. Dat wat Michali zegt in 2 zinnen wordt in dat artikel helder uitgelegt inclusief voorbeelden. Ik kwam het zelf gisteravond tegen nadat ik zelf opzoek was naar errorhandling in PHP5.