Ako ste se ikada našli da ste pisali nekakvu funkciju tipa:
function myBoolean(string){
if(string=='false')return false;
...
}
…ili…
function objectAsBoolean(x){
return objectLength(x) > 0;
}
…vjerujem da ste otišli krivim putem. Znam, jer sam i ja mnogo puta…i nikako mi nije bilo jasno kako tom putu nikada nema kraja.
A nema kraja zato jer se tu postavljaju mnoga pitanja. Krenimo redom:
- Hoćemo li integere 1/0 tretirati kao boolean stanja
- Hoćemo li bilo koji integer tretirati kao boolean stanje
- Hoćemo li numeričke vrijednosti stringa “1/0” tretirati kao boolean stanja true/false
- Hoćemo li string “true”/“false” tretirati kao boolean stanja
- Hoćemo li prazan string tretirati kao false
- Hoćemo li string “null” tretirati kao false
- Hoćemo li string “undefined” tretirati kao false
- Hoćemo li uopće bilo koji string tretirati kao boolean stanje
- Hoćemo li objekte (array/asocc) tretirati kao pozitvno boolean stanje
- Hoćemo li prazne objekte tretirati onda kao false stanje
- Kako ćemo reagirati ako nam u provjeru uleti element za kojega ni sami nismo sigurni kako bi ga tretirali. Bacat grešku ili jednostavno vratiti false.
To gore je 11 pitanja koji se daju odgovoriti sa DA ili NE, što će reći da imamo 11 digitalnih stanja.
A da bi predstavili sve kombinacije za 11 digitalnih stanja, to je 2048 kombinacija.
Stoga, ako ste krenuli pisati custom funkcije za određene provjere…da bi pokrili sve kombinacije…trebalo bi vam podosta funkcija. 
Naravno, parametriziranjem funkcija se smanjuje potreba pisanja različitih funkcija i naravno da želimo imati jednu jedinstvenu funkciju za kontroliranu provjeru Boolean stanja.
Postavlja se pitanje, kako parametrizirati takvu funkciju?
Meni se nekako u praksi pokazalo da je ovakva stanja najelegantnije parametrizirati sa jednim “stringom”, koji zavisno od toga da li sadržava neki karakter ili ne sadržava…utječe na ulazna digitalna stanja.
Npr. zamislimo funkciju element.getWidth()
…od te funkcije možemo željeti da nam vrati:
- unutarnju širinu
- širinu paddinga
- širinu bordera
- širinu margina
- ili širinu svega toga zajedno
- a možda baš trbamo samo unutarnju širinu + širinu paddinga.
…vidimo da nam tako kombinacije ulaznih digitalnih stanja opet enormno rastu i nije ih lako sve pokriti. Ili ipak je?
Zamislimo parametar: “ipbm”.
Gdje svaki nosi jedno digitalno stanje, redom za:
- i inner
- p padding
- b border
- m margine
I sada uvijek možemo pozvati samo onoga tko nam treba, npr: element.getWidth("ip");
Sličnim pristupom mislim da je najelegantnije rješiti stanja za kontrolu tretiranja booleana. Samo mi je malo pofalilo slova, ali što je tu je:
- 1 1/0 as true/false
- d digits, string “1/0” as true/false
- b booleans, string “true”/“false” as true/false
- u string “undefined” as false
- n string “null” as false
- N real null as false
- U real undefined as false
- s any string as true, except declared false strings
- D real digits as true except declared false digits
- e empty object as false
- z zero string length as false
- o any object as true except declared false objects
- t throw error on uncontroled type
Sada se funkcija poziva jako eleganto:
var state = myBoolean(x, "1dbunNUsDezot");
Zaebavam, ovo gore nije elegantno xd xd…ali je poprilično fleksibilno!
A ta fleksibilnost se može konfigurirati negdje u globalnom configu koji će reći funkciji myBoolean kako će se ponašati.
No što smo s time postigli? Pa i ne baš puno…u “normalnom režimu” rada nam je najčešće sasvim dovoljno i ono kako jezik nativno tretira boolean stanja. Pa nema neke potrebe tome doskakati za svaku situaciju. Ali je super biti fleksibilan u onim momentima kada nam ta fleksibilnost zatreba.
A kako na ulazu imamo 2048 stanja, teško da možemo u config fileu pogoditi koja solucija će nam zatrebati…kada ona uvijek može specifična od slučaja do slučaja.
Stoga, ako bi recimo u nekakvoj boolean kontroli htjeli tretirati prazan string kao true stanje …onda bi elegantija sintaksa bila:
var state = myBoolean(x, "-z");
gdje smo iz defaultnog control parametra “1dbunNUsDezot” isključili stanje z koje kaže da tretiramo prazan string as false. Sada ima smisla da se defaultno stanje postavi negdje u konfiguraciji, a onda po specifičnoj situacij možemo:
var state = myBoolean(x, "-z"); //skratiti defaultno stanje
var state = myBoolean(x, "+t"); //extendati defaultno stanje
var state = myBoolean(x, "1beot"); //prepisati defaultno stanje
var state = myBoolean(x, 1044); //numerirano ulazno digitalno stanje
kako imamo ograničen broj ulaznih digitalnih stanja, možemo svako predstaviti i brojem. Istina, ima jako puno brojeva, ali vjerujem da onih zanimljivh za upotrebu bi se isfiltriralo možda svega 15-ak. A 15 brojeva je pamtljivo i definitivno jedna od opcija za definirati ulazno stanje.
I čemu sve to? Zar nije moguće u toj nekoj specifičnoj situaciji upregnuti malo sirove if / else provjere i tako hendlati specifičnu situaciju?
Pa lokalno unutar projekta to nije problem tako napraviti, ali što ako npr. praviš helper komponentu/metodu koja unutar sebe nešto filtrira provjeravajući boolean stanja, gdje tretiranje booloean stanja zavisi od specifične situacije gdje će se ta komponenta upogoniti?
Kako će developer te komponente definirati da radi točno po želji onoga koji će je koristiti, ako ne ostaviš mogućnost taj koji ju koristi, da joj može eksplicitno definirati kako će se ponašati za određenu situaciju.
Gdje se ona naravno defaultno može ponašati nativno po jeziku, ukoliko ne dobije specifičnu naredbu kako će tretirati boolean stanja.
Kako se dosad još nisam sreo da se netko pozabavio ovom problematikom, moj doprinos je:
1dbunNUsDezot
