Ik ben nu bezig met de output van verschillende functies in binairy terug te laten geven zodat ik in 1 keer meer fouten kan terug geven als er iets aan de hand is.
Nu werkt het wel, maar mijn vraag is of het te vergemakkelijken met (korter te maken) is.
<?php
class User{
const R_INVALID_FORMAT_EMAIL = 1;
const R_INVALID_FORMAT_PASSWORD = 2;
const R_UNKNOWN_CREDENTIALS = 4;
const R_CAPATCHA_INVALID = 8;
const R_ATTEMPT_TIMEOUT = 16;
// etc.
public function login($email, $password){
$result = 0;
if(!Validate::email($email)){
$result += self::R_INVALID_FORMAT_EMAIL;
}
if(!Validate::password($password)){
$result += self::R_INVALID_FORMAT_PASSWORD;
}
// Met name, deze lijn met code.
if(~$result & self::R_INVALID_FORMAT_EMAIL && ~$result & self::R_INVALID_FORMAT_PASSWORD){
// since we now must query the database, only do this when both email and password format is correct.
}
return $result;
}
}
?>
De snelheid is in dit geval geen doorslaggevend critrium omdat de checks niet elke page-access worden gebruikt (even uitgaande van het oorspronkelijke voorbeeld, de login() methode van de User class, waarvan mij het nut nog steeds bijster is). Een login mag best 10ms langer duren hoor. De leesbaarheid van zo'n routine lijkt mij belangrijker dan performance. In jouw opzet wordt het ook verdomd lastig om meerdere keren eenzelfde veldtype in een formulier te hebben? Dat is helemaal niet ongebruikelijk hoor.
Ik zeg ook niet dat je een geneste structuur moet gebruiken voor validatie, dat lijkt mij (ook) niet de goede weg. Het enige wat ik denk is dat je met het bovenstaande gebruik de verkeerde weg bent ingeslagen.
Je hoeft ons denk ik ook niet uit te leggen hoe bitwise comparators werken...
Een voorbeeld van juist gebruik van wanneer je zo'n optelsom van binaire waarden als getal opslaat en hiermee vergelijkt is denk ik als je een bepaalde configuratie compact wilt opslaan en hiermee een soort van "status" van een object beschrijft. Deze kun je dan weliswaar ook makkelijk raadplegen maar je moet dan tegelijkertijd heel goed vastleggen:
- wat al deze waarden betekenen
- welke combinaties zijn toegestaan
EDIT: Daarnaast moeten deze verschillende "statussen" tezamen ook een soort van zinnige combinatie vormen die mogelijk een speciale betekenis heeft waar je vervolgens iets mee doet. Het enige wat ik tot nu toe gezien heb is dat je ofwel kijkt of alles goed is (1111111111) of toestanden alleen maar mutual exclusive op kunnen treden, dus
0001 of
0010 of
0100 of
1000) dan lijkt deze hele bitwise business mij toch echt een enorme overkill van complexiteit waarbij je nauwlijks het potentieel benut... omdat je deze niet nodig hebt!
Om het bovenstaande voorbeeld aan te halen: dit kun je reduceren tot twee boolean velden: read en trashed (of deleted ofzo). Of er op gereageerd is is redundante (afleidbare) informatie. Met jouw aanpak krijgt de leesbaarheid een enorme opdoffer en je introduceert tegelijkertijd enorm veel magic numbers (in de vorm van constanten). Je moet met behulp van documentatie dan gaan reverse-engineeren wat de betekenis daarvan is. Gebruik je echter twee kolommen met omschrijvende namen dan zijn deze al bijna volledig zelf-documenterend. Deze zijn op een natuurlijke manier al zonder moeite te ontcijferen.
Ik denk dat je op dit moment een beetje overenthousiast bent over wat je met bitwise vergelijkingen kunt doen en daarmee het praktische aspect een beetje uit het oog verloren bent.
Maar voel je vrij om deze "tangent" verder te verkennen, het lijkt er niet op dat we je enthousiasme met argumenten kunnen beteugelen.
>> Je hoeft ons denk ik ook niet uit te leggen hoe bitwise comparators werken...
Was ook meer voor Ozzie.
>> Een login mag best 10ms langer duren hoor. De leesbaarheid van zo'n routine lijkt mij belangrijker dan performance.
Helemaal mee eens :) Daarbij kost zelfs bitwise comparisons meer rekenkracht omdat (funca() & funcb()) allebij worden uitgevoerd zelfs als funca() false geeft.
>> In jouw opzet wordt het ook verdomd lastig om meerdere keren eenzelfde veldtype in een formulier te hebben?
Ik snap niet echt wat je hier mee bedoeld, in m'n CMS systeem word er een event afgevuurd wanneer er iemand op "login" drukt in een bepaald formulier id. Deze event laad de user->login() met daarbij eventueel plugin code die daarop geregistreerd staan.
>> Gebruik je echter twee kolommen met omschrijvende namen dan zijn deze al bijna volledig zelf-documenterend. Deze zijn op een natuurlijke manier al zonder moeite te ontcijferen.
Klopt, het is zeker moeilijker uit te maken wat-wat is ik zou dus telkens de class constants erbij moeten pakken om te kijken hoe-of-wat.
Maar of ik de verkeerde weg ben opgelopen, ik sta altijd open voor suggesties maar als ik eerlijk ben zie ik geen mooiere uitweg.
In login worden plugins geladen, waaronder Capatcha (of eventuele andere dingen zoals een nieuwsbrief checkbox wat ik nog zou moeten maken) dit is dus instelbaar. Deze plugin wordt ingeladen door &$result te voeren aan de initializer van de plugin en voegt daar zijn eigen flags aan als er iets fout is.
Het werkt prima en is hierdoor heel dynamisch, alleen mag ik niet meer dan 32/64 flags hebben :p
Qua documentatie, ik hou alles prima bij en het gaat toch een systeem worden die ik zelf ga gebruiken.
Maar ik ga er een nachie over slapen, want je hebt zeker gelijk dat het debuggen uit de hand kan lopen, vooral met plugins & code opsplitsingen. Misschien constanten dynamisch laten aanmaken zodat deze van constant naar naam vertaald kan worden en een error kan worden gegeven als er geen ruimte meer is voor nieuwe flags.
Het zit nog allemaal in het begin fase, dus als je een beter idee hebt laat maar horen.
Daarbij kost zelfs bitwise comparisons meer rekenkracht omdat (funca() & funcb()) allebij worden uitgevoerd zelfs als funca() false geeft.
Euh, vergeet niet dat je numerieke waarden vergelijkt bij bitwise comparisons, geen booleans. Het zou heel vreemd, en naar alle waarschijnlijkheid gewoon fout, zijn als je een boolean in zo'n vergelijking gebruikt. De uitkomst van een bitwise comparison zou wederom een getal moeten zijn.
