>> Als je alleen maar OO't om te OO'en, ben je mijns inziens verkeerd bezig.
Dat zeg ik ook niet en ben ik het ook helemaal mee eens. Ik zeg alleen dat als je eenmaal voor je project hebt gekozen om OO te gebruiken, je het ook overal in dat project moet gaan gebruiken. Ik moet er niet aan denken om 1 project met een beetje OO, beetje procedureel en een beetje functioneel aan te pakken. Be consistent :)
maar dan nog is new Error() niet een handige benadering. vooral omdat je steeds in een andere scope dezelfde instantie nodig hebt.
Dan zou je daar een singleton van moeten maken, met alle gezeur van dien.
Static is denk ik het handigste voor dit doel. Zeker aangezien dit functioneel niet zo heel veel meer lijkt te doen dat een string onthouden om later te kunnen weergeven / loggen.
>> Als je alleen maar OO't om te OO'en, ben je mijns inziens verkeerd bezig.
Dat zeg ik ook niet en ben ik het ook helemaal mee eens. Ik zeg alleen dat als je eenmaal voor je project hebt gekozen om OO te gebruiken, je het ook overal in dat project moet gaan gebruiken. Ik moet er niet aan denken om 1 project met een beetje OO, beetje procedureel en een beetje functioneel aan te pakken. Be consistent :)
Dat ga je dus situaties krijgen waarbij je bepaalde functionaliteit in je project geforceerd in OO gaat implementeren, terwijl OO daar helemaal niet voor geschikt is. Het is helemaal geen probleem om dan ook wat procedurele code te gebruiken. Dat heeft niets met consistentie te maken. Het wordt pas inconsistent als je soortgelijke situaties de ene keer OO oplost en de andere keer procedureel.
Als jij denkt dat ik er helemaal niets van begrijp dan denk je verkeerd. Ik verplaats mezelf echter in de situatie van de TS die waarschijnlijk echt voor het eerst probeert met classes te werken. OOP wil ik het nog helemaal niet noemen.
Jouw opmerking over geen echo in functies plaatsen is ook erg kort door de bocht. Ik weet wel dat er omstandigheden zijn waarin je het wel zou kunnen maar dat komt vanzelf wel goed tegen die tijd. (uiteindelijk zul je toch ergens je output kwijt moeten).
Ik vind het jammer, en dat is dan in het algemeen en niet persoonlijk gericht aan willem, dat iedereen hier vooral zijn eigen stem wil laten klinken. Mijn gevoel zegt dat we beginners en hobbyisten hier niet mee helpen.
Goed speciaal voor Willem: Jij bent echt de aller aller beste programmer van het board! (dat is toch wat je graag wilt horen?) Ik zou zeggen succes er mee :-)
Als jij denkt dat ik er helemaal niets van begrijp dan denk je verkeerd. Ik verplaats mezelf echter in de situatie van de TS die waarschijnlijk echt voor het eerst probeert met classes te werken. OOP wil ik het nog helemaal niet noemen.
Je hebt mij niet horen zeggen dat je er niets van begrijpt (in ieder geval niet in de context die jij bedoelt). Ik heb alleen gezegd dat ik die ene coderegel een gedrocht vind.
Als iemand voor het eerst probeert met classes te werken en het niet goed doet, moet je daar bovendien niet in meegaan. Het is over het algemeen gemakkelijker iets meteen goed aan te leren dan iets wat fout aangeleerd is later weer af te leren.
Jouw opmerking over geen echo in functies plaatsen is ook erg kort door de bocht. Ik weet wel dat er omstandigheden zijn waarin je het wel zou kunnen maar dat komt vanzelf wel goed tegen die tijd. (uiteindelijk zul je toch ergens je output kwijt moeten).
Ook hier heb je me verkeerd begrepen. Ik had het niet over het gebruik van een echo in functies, maar over het affreuze gebruik van een dubbele ontkenning in het bijgevoegde commentaar. Als je een beetje bekend met met booleaanse algebra, dan zou je moeten weten dat "nooit geen" hetzelfde betekent als "altijd". In feite zei je dus: "altijd echo gebruiken in methods" en dát vind ik nou niet direct het meest waardevolle advies.
Goed speciaal voor Willem: Jij bent echt de aller aller beste programmer van het board!
Fijn dat we het in ieder geval over één ding eens kunnen zijn. ;-)
Iedereen bedankt voor de reacties.
Jullie zijn allemaal goede programmeurs en in ieder geval beter dan mij.
Helaas lukt het mij nog steeds niet.
Statische methoden zijn bij mij geheel onbekend.
Dit heb ik nu in het bestandje error.class.php staan
<?php
Class error
{
Protected static $melding;
Public static function set_error($msg)
{
self::$melding = $msg;
}
Public static function get_error()
{
Return self::$melding;
}
}
?>
Dit in login.class.php
<?php
include_once "error.class.php"; //error fout probleem class
class Login{
public $bla;
function __construct(){
$this->bla = new Error();
$this->bla::set_error("Foute gebruikersnaam of wachtwoord");
}
Dit in login.php
<?php session_start();
include_once "login.class.php"; //implementeerd het bestand login.class.php in deze pagina
include_once "error.class.php"; //fout probleempje class
if(!empty($_POST["submit"])){ //als er op Login gedrukt wordt voer dit uit
$foutje = new Error();
$login= new Login();
}
?>
<table width="325" border="0" align="center" cellpadding="0" cellspacing="1" bgcolor="#CCCCCC">
<tr>
<form name="bladiebla" method="post" action="<?php $_SERVER['PHP_SELF'] ?>">
<td>
<table width="100%" border="0" cellpadding="3" cellspacing="1" bgcolor="#FFFFFF">
<tr><td colspan="3"><font size="2"><i>Na deze site wordt er gebruik gemaakt van <a target="_blank" href="sessievspermanent.html">sessie cookies </a></i></font></td></tr>
<tr>
<td colspan="3"><strong>Login </strong> </td></tr>
<!-- waar het getoond dient te worden -->
<tr><td colspan="3"><font color="red"> <?php if (!empty($_POST["submit"])){ echo $foutje::get_error(); } ?> </font> </td> </tr>
Iedereen bedankt voor de reacties.
Jullie zijn allemaal goede programmeurs en in ieder geval beter dan mij.
Helaas lukt het mij nog steeds niet.
Statische methoden zijn bij mij geheel onbekend.
Kijk dat bedoel ik nou. Arnold probeert het principe van classes te gebruiken, komt daarmee met een vraag op dit board en de termen vliegen om zijn oren!
- Statische methods
- Singletons
- OOP
- Scope
Ik zou als ik jou was de bovenste twee vergeten voorlopig.
De moed om je te helpen is ontnomen door ene Willem WijsNeus.
[tab][color=red]modmelding[/color]
Heren, laten we de druk hier niet te hoog gaan opvoeren. Willen jullie, Frank en Willem, nog verder discussiëren over elkaars reactiewijzes, dan kan dat via een PM[/tab]
