VNC stopt er mee :(
Bitwise operators meerdere flags vergelijken
Ik heb al wat gevonden, eigenlijk heel makkelijk:
Code (php)
1
<?php if(!$result & self::R_INVALID_FORMAT_EMAIL + self::R_INVALID_FORMAT_PASSWORD){ ?>
----
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.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
<?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;
}
}
?>
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;
}
}
?>
Gewijzigd op 28/08/2015 20:36:01 door Johan K
~$result
Net zoals ! op een boolean doet.
Code (php)
Gewijzigd op 28/08/2015 17:25:15 door Johan K
>> het draait de nulletjes en eentjes om
Kun je dat eens iets uitgebreider uitleggen. En vraag 2 ... wat kun je ermee?
Validate::email("ozzie") -> false (geen email aderes).
Validate::password("test") -> false (omdat minimal string length 6 moet zijn)
De waarde die word terug gekeerd is in dit geval 1 + 2 = 3.
Deze login request word door een ajax request gedaan en stuur 3 door via json.
Nu weet ik door 1 getal dat zowel de username en password fout zijn door de binaire representatie: "00000011" en kan dit direct aanpassen in het login form.
Tweede voorbeeld:
Neem deze code, stel dat de gebruiker inlogd met "[email protected]" en als wachtwoord "test".
De waarde die word terug gekeerd is in dit geval 2 in binair "00000010"
Nu weet ik dat het wachtwoord foutief is, en de email correct.
Dus wat je er eventueel met de "~" mee zou kunnen doen is kijken of alle "flags" goed zijn, behalve het wachtwoord. Het is een not operator op meerdere booleans. In mijn geval, draai ik "0" de standaard waarde van result om in alles. Ik kan ook de result de waarde geven van (16*2) - 1 om alle flags als 1 te zetten.
Beetje hetzelfde als de E_ALL constant.
Gewijzigd op 28/08/2015 19:36:02 door Johan K
Thomas van den Heuvel op 28/08/2015 17:41:36:
Ik weet niet of bitmaskers heel erg toepasselijk zijn voor deze manier van valideren. Waarom doe je dit niet gewoon zonder? Als je dit gebruikt om bij te houden wat valideert, houd dit dan gewoon per veld bij, in plaats van deze opzet?
Mijn opzet is dat alle code wat in het systeem draait taal onafhankelijk is, dus strings terug geven met daarin de fout is dus een no-no. Als ik booleans ga terug keren dan is de vraag, wat is er fout? Bitmasks past perfect in dit plaatje en het is nog erg snel ook.
Als ik eerlijk mag zijn heb ik vrij weinig met bitwise operators gewerkt, daarom mijn vraag ook. Ik neem aan dat ik iets van if($result & (FLAG_A & FLAG_B)){} kan doen maar wat ik ook probeer het resulteerd in of allebij true of false.
Als je formulier ook wat uitgebreider wordt of wanneer je velden van volgorde gaat veranderen is het overzicht al snel weg denk ik (de constanten die machten van 2 zijn worden al snel vrij groot). Daarom stelde ik voor dat je gewoon per veld (en bij het veld zelf, en niet met allerlei hardcoded numerieke waarden) bijhoudt of deze geldige inhoud bevat of niet.
Ook snap ik niet helemaal wat dit in een user Class doet. Wat zou de login() methode moeten teruggeven, en wat betekent dat? Ik zou verwachten dat een login() methode van een User class iets doet met "inloggen", maar dit controleert enkel (het format van?) invoervelden, en verder niets?
Bovenstaande syntax ziet er al vrij complex uit. Als er iets helder en transparant moet zijn is het wel je loginroutine... Booleans debuggen lijkt mij nog altijd makkelijker dan zoiets terugkrijgen: "010101100101111010111101011111010111110001111" en dat je dan zegt "Ooooh, er staat een 1 op positie 28 verkeerd, dat ik dat niet eerder zag".
:)
Gewijzigd op 28/08/2015 18:04:06 door Thomas van den Heuvel
Thomas van den Heuvel op 28/08/2015 18:02:48:
Ook snap ik niet helemaal wat dit in een user Class doet. Wat zou de login() methode moeten teruggeven, en wat betekent dat? Ik zou verwachten dat een login() methode van een User class iets doet met "inloggen", maar dit controleert enkel (het format van?) invoervelden, en verder niets?
Bovenstaande syntax ziet er al vrij complex uit. Als er iets helder en transparant moet zijn is het wel je loginroutine... Booleans debuggen lijkt mij nog altijd makkelijker dan zoiets terugkrijgen: "010101100101111010111101011111010111110001111" en dat je dan zegt "Ooooh, er staat een 1 op positie 28 verkeerd, dat ik dat niet eerder zag".
:)
Bovenstaande syntax ziet er al vrij complex uit. Als er iets helder en transparant moet zijn is het wel je loginroutine... Booleans debuggen lijkt mij nog altijd makkelijker dan zoiets terugkrijgen: "010101100101111010111101011111010111110001111" en dat je dan zegt "Ooooh, er staat een 1 op positie 28 verkeerd, dat ik dat niet eerder zag".
:)
Dit is ook maar een sample code, het weglaten van dingen die er niet toe doen aan de vraag en ik had voor dit voorbeeld de waardes simpelweg aangepast.
Over het debuggen, daarom werk je ook met constanten en niet echt met binaire data. Je kijkt alleen of er een constant actief is in het getal, niets gecompliceerd aan het is alleen een andere werk methode.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
<?php
if(($r = User::login($user, $pass)) !== true){
if($r & User::R_INVALID_FORMAT_EMAIL){
echo 'Some javascript code to mark the email field red with an error message perhaps.';
}
if($r & User::R_INVALID_FORMAT_PASSWORD){
// Oh, what specifically went wrong with the password?
$t = Validate::password($pass);
if($t & Validate::R_PASSWORD_LENGTH_MIN){
// password is shorter then minimum length
}
if($t & Validate::R_PASSWORD_NO_SYMBOL){
// password does not contain symbols.
}
if($t & Validate::R_PASSWORD_NO_DIGIT){
// password does not contain any digits.
}
}
}
//in plaats van:
if(!User::login($user, $pass)){
if(Validate::email($user)){
if(emailExists($user)){
//etc
}
}
if(Validate::password($pass)){
// etc
}
}
?>
if(($r = User::login($user, $pass)) !== true){
if($r & User::R_INVALID_FORMAT_EMAIL){
echo 'Some javascript code to mark the email field red with an error message perhaps.';
}
if($r & User::R_INVALID_FORMAT_PASSWORD){
// Oh, what specifically went wrong with the password?
$t = Validate::password($pass);
if($t & Validate::R_PASSWORD_LENGTH_MIN){
// password is shorter then minimum length
}
if($t & Validate::R_PASSWORD_NO_SYMBOL){
// password does not contain symbols.
}
if($t & Validate::R_PASSWORD_NO_DIGIT){
// password does not contain any digits.
}
}
}
//in plaats van:
if(!User::login($user, $pass)){
if(Validate::email($user)){
if(emailExists($user)){
//etc
}
}
if(Validate::password($pass)){
// etc
}
}
?>
Je vergelijk je alleen de flags/constants en zit je niet te kloten met functies of andere input data want alles word al behandeld in User::login(). Dit resulteert alleen maar in kortere, snellere (omdat je niet twee keer dezelfde functie hoeft aan te roepen) en meer overzichtelijke code naar mijn idee.
Deze code (login) gaat waarschijnlijk nog wel een andere locatie of andere constant namen krijgen, ik zit er gewoon momenteel even mee te "spelen" wat het lekkerste werkt.
En niet alleen deze functie gaat zo lopen, bitwise operators zijn heel krachtig en kunnen op veel plekken gebruikt worden. Het is ook niet de vraag waarom, maar hoe. Ik wil er wat meer ervaring mee op doen en hoopte dat iemand hier dat ook had en of hij of zij dit iets anders zou schrijven.
Gewijzigd op 28/08/2015 19:30:02 door Johan K
>> De waarde die word terug gekeerd is in dit geval 2 in binair "00000010"
En waarom dan binair? Waarom niet gewoon 2?
>> Mijn opzet is dat alle code wat in het systeem draait taal onafhankelijk is, dus strings terug geven met daarin de fout is dus een no-no. Als ik booleans ga terug keren dan is de vraag, wat is er fout?
Je kan toch met exceptions werken en dan bijv. foutcodes meesturen?
Als je kijkt naar het script, geef ik ook gewoon een getal terug.
Waar het om gaat is hoe bitwise operators werken, die vergelijkt de bitjes van het getal en niet direct de waarde.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
<?php
$a = 1; // 0001 3 = 0011
$b = 2; // 0010 5 = 0101
$c = 4; // 0100 6 = 0110
$d = 8; // 1000 7 = 0111
echo 3 & $a; // aangezien het laatste bitje van 1 overeenkomt met het laatste bitje van 3, geeft hij de bitwaarde van 0001 terug dus in ditgeval het getal "1".
echo 6 & ($b | $a); // de waarde van 6 komt niet overeen met de bitjes van $a (1), wel van $b (2), ik vergelijk dit met $a of $b, in dit geval $b dus "2".
// In het voorbeeld kan je 3 terug krijgen van de functie (0011) als je wachtwoord en email fout zijn, nu met deze code kan je kijken wat er fout is.
if(3 & 1){
echo 'bitje van 3 (0011) zit ook in 1 (0001).';
}
if(3 & 2){
echo 'bitje van 3 (0011) zit ook in 2.(0010)';
}
if(3 & 3){
// deze is overbodig want dit word nu dubbel uitgevoerd omdat 1 & 2 dit al hebben gedaan.
echo 'bitje van 3 (0011) zit ook in 3 (0011).';
}
if(3 & 4){
echo 'bitje van 3 (0011) zit -niet- in 4 (0100)';
}
?>
$a = 1; // 0001 3 = 0011
$b = 2; // 0010 5 = 0101
$c = 4; // 0100 6 = 0110
$d = 8; // 1000 7 = 0111
echo 3 & $a; // aangezien het laatste bitje van 1 overeenkomt met het laatste bitje van 3, geeft hij de bitwaarde van 0001 terug dus in ditgeval het getal "1".
echo 6 & ($b | $a); // de waarde van 6 komt niet overeen met de bitjes van $a (1), wel van $b (2), ik vergelijk dit met $a of $b, in dit geval $b dus "2".
// In het voorbeeld kan je 3 terug krijgen van de functie (0011) als je wachtwoord en email fout zijn, nu met deze code kan je kijken wat er fout is.
if(3 & 1){
echo 'bitje van 3 (0011) zit ook in 1 (0001).';
}
if(3 & 2){
echo 'bitje van 3 (0011) zit ook in 2.(0010)';
}
if(3 & 3){
// deze is overbodig want dit word nu dubbel uitgevoerd omdat 1 & 2 dit al hebben gedaan.
echo 'bitje van 3 (0011) zit ook in 3 (0011).';
}
if(3 & 4){
echo 'bitje van 3 (0011) zit -niet- in 4 (0100)';
}
?>
>> Je kan toch met exceptions werken en dan bijv. foutcodes meesturen?
Dat kan, je kan ook met arrays werken je kan van alles doen en laten wat je zelf wilt.
Maar is het snel? Een heel object aan te maken om alleen maar een getal terug te sturen? Wat ik hier doe is op bit niveau, geen objecten gewoon getallen.
Persoonlijk gebruik ik alleen exceptions op kritische fouten en niet voor return values.
Hoewel je nu het praktische nut er misschien niet van ziet, bekijk dit scenario.
ik verstuur een mail naar de inbox van een gebruiker en heb de volgende kolommen in de database. (id, message, status) de status staat standaard op 0.
Nu print ik deze mail uit in een tabel en kijk op status.
Status: 0 = unread, 1 = read, 2 replyed, 4 trashed
Als de gebruiker het bericht opent, zet ik de status op +1.
Wanneer de gebruiker antwoord geeft op het bericht, zet ik de status op +2 (3)
Wanneer de gebruiker het verwijderd, gaat de status naar +4 (7) in dit geval.
Met bitwise operators kan je heel makkelijk kijken wat de status is.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<?php
const UNREAD = 0;
const READ = 1;
const REPLYED = 2;
const TRASHED = 4;
const READ_AND_TRASHED = TRASHED + READ;
if($status & UNREAD ){ //unread }
if($status & READ ){ //read }
if($status & REPLYED ){ //replyed }
if($status & 3 ){ //read and replyed }
if($status & (READ + REPLYED) ){ //read and replyed }
if($status & TRASHED ){ //unread and trashed }
if($status & READ_AND_TRASHED ){ //read and trashed }
if($status & 6 ){ //replyed and trashed }
if($status & 7 ){ //read, replyed and trashed }
// Je kan met 0, 1, 2, 4 een maximale waarde maken van 7.
?>
const UNREAD = 0;
const READ = 1;
const REPLYED = 2;
const TRASHED = 4;
const READ_AND_TRASHED = TRASHED + READ;
if($status & UNREAD ){ //unread }
if($status & READ ){ //read }
if($status & REPLYED ){ //replyed }
if($status & 3 ){ //read and replyed }
if($status & (READ + REPLYED) ){ //read and replyed }
if($status & TRASHED ){ //unread and trashed }
if($status & READ_AND_TRASHED ){ //read and trashed }
if($status & 6 ){ //replyed and trashed }
if($status & 7 ){ //read, replyed and trashed }
// Je kan met 0, 1, 2, 4 een maximale waarde maken van 7.
?>
Gewijzigd op 28/08/2015 21:53:14 door Johan K
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.
Gewijzigd op 28/08/2015 23:41:54 door Thomas van den Heuvel
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.
Johan K op 29/08/2015 00:35:59:
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.
Het is trouwens CAPTCHA, niet CAPATCHA.
Johan K op 29/08/2015 00:35:59:
Het zit nog allemaal in het begin fase, dus als je een beter idee hebt laat maar horen.
Als je aan kunt geven wat je nu precies probeert te bereiken kunnen we wellicht tot een betere aanpak komen.
Gewijzigd op 29/08/2015 14:16:38 door Thomas van den Heuvel