Potakla me tema Boolean controler koju sam nekidan otvorio da skužim jednu zanimljivu stvar, pa ću i to da podijelim.
Kopirat ću sljedeći dio na koji se osvrćem:
E sad, dalo mi je to misliti zašto je nekada taj pristup ok, a zašto nekada nije?
Jer ako je to OK pristup, zašto nam svi parametri nebi izgledali tako? hehe
Pa fora je sljedeća, takav parametar ima sposobnost opisati samo digitalna stanja na ulazu.
Primjer digitalnih/binarnih stanja npr. jednog grada:
//grad
{
vodovod:1,
kanalizacija:1,
elektrana:0,
telefon:1,
}
…i ono što se ne da opisati digitalnim stanjima:
//auto -
{
godiste:1998,
total_km:225000,
vrata:5,
...
}
Što me navodi na sljedeći cool ideju. (barem meni cool ideju )
Svaki puta kada imamo parametar koji je skup digitalnih stanja, on se može opisati jednim flag-stringom.
Npr. gornjem gradu bi bio ekvivalent stringu: “vkt”. Drugim riječima, “vkt” nam može biti dovoljna informacija da ga extractamo u:
{
vodovod:1,
kanalizacija:1,
elektrana:0,
telefon:1,
}
…ako smo negdje ranije definirali (inicijalizirali) naš digitalni-flag parametar, gdje bi njegova definicija izgledala ovako:
var digitalFlagTemplate = {
vodovod:1,
kanalizacija:1,
elektrana:0,
telefon:1,
__shorthands__:"vket"
}
Što nam ta definicija govori? Govori nam par stvari:
- pokazuje koja sva digitalna stanja sadrži parametar. To su (vodovod, kanalizacija, elektrana, telefon)
- pokazuje nam koja su defaultna stanja tih parametara, redom to su “1 1 0 1”.
- pokazuje nam koji su shorthands alias karakteri za ta digitalna stanja, redom to su “v k e t”
Sada kada imamo to, imamo sve potrebne informacije da transformiramo zadani flag u string formatu u potpuni parametar koji dalje može ići kompletan na upotrebu. Npr. evo par transformacija:
Flag: undefined ->
{
vodovod:1,
kanalizacija:1,
elektrana:0,
telefon:1
}
//flag undefined će rezultirati defaultnim stanjem prema inicijalnoj definiciji parametra
Flag:"vk" ->
{
vodovod:1,
kanalizacija:0,
elektrana:1,
telefon:0
}
//flag "ve" postavlja samo true stanja vodovodu i elektri.
//Nadalje, unziper flag stringa bi mogao razumjeti neke dodatne naredbe. Npr. ako flag prethodi minusom, da samo oduzme ta stanja iz defaultne definicije, tako npr:
Flag:"-v" ->
{
vodovod:0,
kanalizacija:1,
elektrana:0,
telefon:1
}
//...postavlja sva stanja kao što su defaultna, osim vodovoda koji je oduzet.
// Istim pristupom možemo imati pravilo za dodavanje stanja na defaultnu definiciju:
Flag:"+e" ->
{
vodovod:1,
kanalizacija:1,
elektrana:1,
telefon:1
}
// u ovom slučaju opet imamo sve kao što je defaultno stanje, osim što smo dodali "e" i tako zadali da je i elektrana true.
Uvođenjem ovako nečega, funkcije koje primaju parametar koji je sačinjen od digitalnih stanja…moglo bi im biti sasvim svejedno jel onaj tko je pisao input, napisao ga u “flag as string” formatu…ili je tipkao kompletan objekt sa svim ključevima i pripadajućim binarnim stanjima.
Btw. prije nego zaskoči netko da je pristup glup.
-
JS nativno u nekim metodama koristi ovaj pristup zadavanja parameta. Npr flagovi u regularnim izrazima su upravo to. Flag “gi” tako kaže:
-
g - radnja je globalna
-
i - radnja je case insensitive
I to je full praktično kontroliranje takvih (digitalnih) ulaznih parametara, što se i meni pokazalo na nekim funkcijama koje sam na taj način parametrizirao.
Samo mi se sada upalila lampica kako to dići na viši nivo.
I onda slijedi odgovor na uvodno pitanje
Jer ako je to OK pristup, zašto nam svi parametri nebi izgledali tako?
Možemo ići ovim pristupom za svaku situaciju gdje je ulazni parametar sačinjen isključivo od digitalnih stanja. Ako ga uvedemo na način kako sam gore opisao, onda smo developeru ostavili fleksibilnost hoće li taj parametar tipkati na klasičan način (navođenjem punog imena svakog ključa parametra), ili će se poslužiti “shorthand” sintaksom, gdje je dovoljno da sa svega par karaktera opiše puno toga.
NormJS just get new toy.