Novi tipovi varijabli - kako vam se čine i kako bi ih nazvali

[bozoou]

@ajme

i jako čudne sintakse

Od sintakse se očekuje par uvjeta:

• da je jednoznačna
• da je lako razumljiva čovjeku i računalu (compailerima)
• da je jednostavna za tipkati čovjeku

Ova moja sintaksa ne narušuje ništa od tih pravila i zapravo nije uopće čudna, nego uobičajena u nekim nižim programskim jezicima. Tamo imaš logiku da se u zaglavlju skripte nabroje sve varijable onda otvaraš mainloop { … } u koji ide code koji radi sa tim varijablama. To je iz razloga jer se nekada više štedilo na registrima i zauzeću memorije koje će program koristiti …pa se unaprijed moralo znati koje sve varijable su u igri i koliko će bitova iste zauzeti.

Ja iz određenih razloga da bi ispunio zamišljenu funkcionalnost ovih tipova varijabli, isto moram unaprijed znati koje varijable će se koristiti u bloku sa vitičastim zagradama { … }, tako da sam pribjegao istom pristupu.

@ajme

Da li je sticky dostupan i u ovom bloku? Ako nije, zašto nije? Ako je, zašto je?

Je, dostupan je. Logika je dosta jednostavna…prvo pobrojiš sve varijable koje će se koristiti u tom bloku, zatim otvaraš blok. Sticky counter tako po ničemu tu nije drugačiji od uservar name i uservar age. Pri tome scope varijable živi točno ondje gdje je ona definirana…ali je spremna za korištenje tek u tom bloku nakon.

Ono što se meni jedino ne sviđa, ja bi da se piše još čišći code:

sticky counter;
uservar name, age;
{

}

No to sam zasada preskočio.Čisto iz razloga jer mi neki kompajleri to trenutno ne mogu progutati jer to više nija validna javascript sintaksa. Dok gornju sintaksu javascript vidi kao validnu, samo njima ima drugo značenje. Ti compaileri ne znaju što će naknadno ti stringovi proći…nego ih vide kao najobičnije stringove…
Zato je "@use uservar name, age"; umjesto samo uservar name, age; Ali u jednom momentu ću to lako moći transformirati u još više clean verziju, za sada mi je ok.

@ajme

Sama izvedba bi imala smisla kao package kojeg onda koristiš ovako:

import { useSticky, useTabvar } from 'čušpajz';

const [ sticky, setSticky ] = useSticky({
	counter: 0
});

setSticky({
	counter: 5
});

Ovo nikako nije rješavanje problema na razini compilera i sintakse…nego nešto sasvim drugo.
I ako poredim taj tvoj prijedlog code-a, spram ovog:

sticky counter = 5;

…jasno mi je bez dvoumljenja da želim pisati ovo drugo.
Programski jezici evoluiraju na način da uvijek sa manje sintakse možemo opisati više pravila …a ne obratno. Ovo tvoje onda nikako nije evolucija sintakse…a niti je uopće rješavanje problema na toj razini sintakse. Nemoj brkati metode sa pravilima ugrađenima na razini sintakse.

@ajme

I onda ovaj tvoj lib mogu koristiti svi bez dodatnih loadera koji trebaju parsirati taj tvoj file.

Kada bi mi to bio interes, išao bi drugim putem. Nemam nikakvih interesa da moj lib netko koristi, nego da unaprijedi i ubrza mene.
No moj lib će moći drugi koristiti, ali to se možda više neće niti zvati javascriptom. Jer radim nešto poprilično novo… i taj lib će se moći koristiti u posebnom containeru koji će biti namjenjen za to. Isto kao što je browser namjenjen da unutra vrtiš javascript, tako će se moj lib vrtiti unutar sistema koje sam nazvao “Doors”.

@ajme

Koji su benefiti korištenja alternativne sintakse u odnosu na plain JS?

Otprilike kao da izađeš iz ovog svijeta koji je ograničen nekakvim pravilima…i uđeš u svijet snova gdje sam možeš kreirati svoja pravila. Postaješ tako neograničen i mogućnosti su beskrajne.
Recimo primjer, dok javascript nije uveo ECMAScript 6, svi koji su tipkali plain javascript nisu imali mogućnost da koriste bilo što od toga. A ja sam si neke od tih stvari sam omogućio prije nego je stigao ECMAScript 6. Kad je stigao ECMAScript 6, dobio sam samo potvrdu da sam ispravno razmišljao i išao pravim putem. Shvatio sam prednost koju sam imao i nastavio još jače tim putem.
Pisao sam o tome: Zašto pre-kompajlirati code
Ja to radim već dosta dugo i mogu reći da imam većinom benefite. Postoje naravno i minusi, ali Bože moj…sve ima svoju cijenu.